Как выбрать между карточками и списком в интерфейсе

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

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

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

Определите, что ищет человек

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

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

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

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

Pinterest и пример отслеживания взгляда показывают разные издержки

Интерфейс Pinterest из статьи NN/G объединяет изображения, заголовки и дополнительные сведения в контейнеры разной высоты. Это соответствует коллекции, где изображение помогает узнавать объект, а объём материала различается. Скриншот ниже показывает тот исторический интерфейс.

В той же статье есть сессия отслеживания взгляда: участник искал интересный материал в карточном макете. Траектория показывает повторные переходы между кандидатами. NN/G связывает это с отсутствием очевидной последовательности ранжирования и разным положением сравнимых сведений.

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

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

Решите, что должно быть видно до открытия записи

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

Прочитайте контент до выбора контейнера

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

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

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

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

Разбор примера: одна библиотека, два начальных представления

Представьте шесть вымышленных проектов: Cedar Lodge, Harbor Rooms, Studio North, Maple Clinic, Archive House и Lumen Shop. У каждой записи есть миниатюра, ответственный, статус проверки и срок. При изменении представления эти поля не меняются.

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

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

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

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

Пусть каждое представление поддерживает свою задачу

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

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

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

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

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

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

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

Списки: сохраняйте надёжный путь просмотра

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

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

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

Вторую строку используйте осмысленно: для короткого описания или уточнения, например рабочего пространства. Не повторяйте заголовок другими словами. «Проект сайта для Cedar Lodge» под «Сайт Cedar Lodge» добавляет длину, но почти не помогает идентификации.

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

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

Определите поведение клика до превращения всего в ссылки

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

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

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

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

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

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

Добавляйте переключатель, только если оба вида оправданы

Переключатель карточек и списка полезен, когда одна аудитория действительно чередует узнавание и систематический просмотр. Он мало даёт, если одна версия просто слабее другой. Два вида также удваивают число состояний контента и деталей взаимодействия для проверки.

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

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

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

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

Сохраняйте задачу на узком экране

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

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

Пусть дополнительные поля переносятся или уходят на вторую строку в заданном порядке. Статус не должен становиться необъяснённой цветной точкой ради места. Если поле раскрывается отдельно, проверьте возможность выполнить основную задачу без открытия каждой записи.

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

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

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

Не спрашивайте только о предпочтении. Дайте задачу с наблюдаемым ответом. Для визуального поиска в библиотеке — проект со сдержанным направлением для гостиничной сферы; для известного объекта — Archive House; для административного просмотра — самая ранняя проверка, назначенная конкретному человеку.

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

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

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

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