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

«Если бы у меня был час на решение проблемы, я бы потратил 55 минут на размышления о ней и 5 минут на поиск решения». Неизвестный

Это так заманчиво: сразу схватиться за бумагу, Sketch или Axure и начать дизайнить. В сферах, где скорость выполнения задач в приоритете, легко нырнуть в проект без подготовки. Исследования и стратегия выглядят, скорей, как барьеры для скорости выполнения заказа. Но что, если на самом деле они помогают ускорить продакшн?

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

С таблицами сложно

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

Таблицы разных линеек продуктов компании

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

Наш Visual Design Lead делегировал команде отдельные элементы пользовательского интерфейса. Надо признать, что когда нам достались таблицы, мы насторожились. Это был паттерн, который использовался почти в каждом продукте. Что еще сложнее, продукты CareerBuilder обслуживали несколько типов пользователей: соискателей работы, рекрутеров и отдел кадров. Каждый продукт кардинально отличается в зависимости от сценариев использования, целей пользователя и функционала. Как можно создать что-то достаточно гибкое для всех этих целей?

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

Начало

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

1. Что пользователь вообще пытается сделать в таблице? На коллективном созвоне мы рассмотрели несколько примеров из patterns.com и попытались экстраполировать цели и задачи таблицы. В итоге мы пришли к выводу, что у пользователя при работе с таблицами 3 цели:

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

Примеры таблиц

2. Каковы главные вызовы дизайна таблиц?

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

3. Можем ли мы разбить таблицу на более мелкие части? Мы разделили ее на следующие составляющие:

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

Мы разделили компоненты между собой.

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

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

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

Заметки и наброски таблиц

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

Для этого мы использовали Sketch и внутреннюю библиотеку стилей, которую загрузили с помощью Craft.

Наш процесс (Ада)

Компоненты таблицы

Если вы сами рисуете таблицу, смотрите, что мы сделали со всеми компонентами (здесь использованы несуществующие данные, чтобы сохранить UI независимым от контента):

Нумерация страниц

Раньше у нас была простая строка нумерации, на которой отображалось количество результатов. Что будет, если поиск вдруг выдаст сотни страниц, а вы хотели перейти на страницу 563? Было бы неудобно постоянно проходить через 562 страницы, чтобы добраться до нужной, поэтому мы внедрили инпут «Перейти к странице». Также мы включили выпадающий список «Показать X результатов», чтобы пользователь мог управлять просмотром. Наш полный арсенал нумерации выглядел так:

Нумерация

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

Поведение нумерации во время перехода пользователя по разным страницам

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

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

Разные варианты отображения для нумерации страниц (Марк Паттерсон)

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

Режимы редактирования

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

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

Другая проблема такого подхода в том, что пользователь мог очень легко допустить ошибку. Можете представить, насколько легко случайно отредактировать не ту ячейку. А как же отменить шаг? Отменить действие? Все сохраняется автоматически? Непонятно.

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

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

Иконки редактирования — по умолчанию серые

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

Когда пользователь нажимает на карандаш, текстовое поле ввода появляется рядом с зеленой галочкой и красным «x». На наших тестовых сессиях пользователи легко поняли, как изменить содержимое ячейки, как только нажали на карандаш. Оказывается, такое упрощение дает результаты!

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

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

Финальный вид «режима редактирования»

Внешний вид кнопок призывов к действию

Как упоминалось выше, вид call to action кнопок (CTA) менялся больше всего во всех прототипах. Иногда CTA находились в верхней части внутри таблицы, иногда вверху в виде кнопки, иногда в ячейках таблицы в виде кнопок или иконок, иногда в выпадающем меню — они были разбросаны повсюду.

Поскольку одна из целей при использовании таблицы — быстро выполнить определенное действие, мы знали, что нельзя заставить пользователей просматривать всю таблицу в поисках этого действия. Все нужно собрать в одном месте. Мы также задумались: будут ли CTA текстовыми ссылками в конце строки? Или вверху таблицы? Нужны ли им иконки? Что, если существует более 4 действий? Как сохранить полезное пространство для остальных столбцов? Мы взяли за правило размещать все действия в конце строки:

Таблица с одним действием в строке: отображается иконкой и подписью

Таблица с 2 действиями в строке: отображается как текстовая ссылка

Таблица с более, чем 2 действиями в строке: отображается в виде выпадающего меню.

Мы отобразили максимум 2 действия, чтобы предоставить пользователю оперативный доступ к ним. Но поскольку три действия занимают достаточно много места в таблице, мы помещаем их в выпадающий список. В течение нескольких раундов итераций мы обсуждали, использовать или не использовать иконки с подписями. Поскольку мы не знаем всех возможных вариантов использования таблицы в будущем, то решили, что иконки могут заставить дизайнера искать примеры для изображения довольно сложных действий, как, например, «[example.]»

Режим редактирования

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

И, конечно, как насчет применения действий к нескольким строкам? Это был бы настоящий геморрой щелкать на столбец действия, а затем на него же еще в нескольких строках. Мы позаимствовали паттерн у Gmail, где при выборе хотя бы одной строки, сверху появляется панель «Применить к нескольким объектам». Внешний вид панели в Gmail был слишком неприметным, поэтому мы кардинально изменили цвет, чтобы привлечь внимание пользователя.

Применения действия к нескольким объектами

Настройка таблицы

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

Настройка таблицы

Ограничение ячейки

При ограниченном пространстве в некоторых из этих ячеек неизбежно возникают проблемы с длиной содержимого. Разрешаем ли мы перенос текста в ячейке? Первоначально нас вдохновил этот шот Вирджила Пана на Dribbble:

Сетка данных дизайнера Вирджина Пала (оригинальный шот на Dribbble)

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

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

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

Ограниченная ячейка таблицы и всплывающая подсказка

Использование изображений и иконок

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

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

Два варианта дизайна «предупреждений» в таблице (Рейчел Дудзяк)

Визуальные индикаторы для просмотренных и непросмотренных объектов

Мы занялись изучением цветных точек и вертикальных полос для обозначения непрочитанных объектов. Точка удачно вписалась в таблицу. Чтобы сделать ее более заметной, мы также выделили текст в строке точки. Затем наши коллеги задали еще один вопрос: как насчет флажков? Точка будет находиться рядом с первой ячейкой (с флажком) или второй (с текстом)?

Первое решение для «непросмотренных» объектов

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

Состояние «непрочитанного» объекта

Расширенный просмотр

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

Пример шаблона расширенного просмотра с Patternfly

Расширенная строка — серая. Она существенно отличается от остальных строк. Связанный контент находится в ограниченном прямоугольнике.

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

Расширенная таблица (Kosten Kos)

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

Первая и вторая итерации расширенной строки

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

Третья итерация расширенной строки: более жирная полоска

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

Четвертая итерация расширенной строки: серая полоска

Визуальные стандарты

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

Оформление отступов и полей (Ada)

Презентация и тестирование таблицы

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

Несмотря на положительный фидбек от нашей команды, мы хотели подтвердить наши предположения: так же это принципиально важно для пользователя извне, как и для нас? Будет ли пользователь знать о доступе к кнопкам действий из выпадающего списка? Запутывает ли пользователей исключение для действия «Редактировать»? Была ли понятна нумерация страниц? Мы объединились с исследователями пользовательского поведения, Кьяни Спеарманом и Майклом Пейтом, чтобы провести базовые тесты юзабилити через UserTesting.com. Исследователи помогли нам разработать тест, который направит пользователя на выполнение 3 действий:

1. Попросите пользователя произвести некоторые действия над элементом.
2. Спросите пользователя, сколько элементов находится в списке и на какой странице они находятся.
3. Попросите пользователя отредактировать чей-то адрес электронной почты.

10 видео с UserTesting.com пришли к нам в течении 2 часов после публикации.

Результаты пользовательских тестов

Об обнаружении кнопок действий в выпадающем списке:

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

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

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

Главные выводы

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

1. Встречайтесь с коллегами на ранней стадии процесса и прописывайте план захвата. Делайте шаг назад, чтобы спросить себя «Почему?»
2. Вкладывайте больше времени на определение проблемы, чем на поиск решения.
3. Избавьтесь от плохих идей быстро. Покажите людям свои идеи на ранней стадии и проанализируйте ответную реакцию, критику, проблемы и т. д. Сразу предлагайте несколько вариантов, чтобы не тратить время на решения, которые не будут работать.
4. Разделите проект на небольшие, более выполнимые части и регулярно их обсуждайте. Разделите между участниками прорабатываемые компоненты, а затем сверьте результаты.
5. Не вмешивайте сюда эго! Поскольку мы заранее определили наши цели и задачи, то сразу на них и сосредоточились, отбросив эмоциональные привязанности к решениям. Это упростило принятие и внедрение замечаний.

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

Мега-благодарность Ариэлю Кейсону за столь тщательный обзор и редакцию этой статьи! Также благодарим Рине Андрееву и Тима Уорда.

С оригиналом статьи можно ознакомиться по ссылке.

Перевод — Катя Павлевич.