В этом выпуске: о визуальных метафорах для действий «мне понравилось» и «хочу сохранить на будущее», переводе WCAG 2.0, подготовке дизайнерского портфолио, ошибках продуктовых дизайнеров, дизайне данных, удобстве рабочих таблиц.
Иконки «палец вверх», «сердце», «закладка» и «звезда»
Чем отличаются иконки «палец вверх», «сердце», «закладка» и «звезда», и что каждая значит по мнению большинства пользователей?
Вспомнил примеры использования этих метафор в интерфейсах и поделился своим мнением:
- Они подходят, чтобы выделить объект в неком позитивном ключе: а) Мне нравится, что здесь написано; б) Это может мне пригодиться;
- Выбор конкретной метафоры зависит от общей функциональности продукта и его тематики;
- Обычно в одном интерфейсе не задействуют одновременно: закладки и звёздочки, сердечки и пальцы вверх.
Доступность веб-контента
Руководство по обеспечению доступности веб-контента — WCAG 2.0 — уже давно создали в W3C и перевели на русский.
Рекомендации помогают сделать сайт доступнее для более широкого круга пользователей с ограниченными возможностями — с нарушениями зрения, слуха, опорно-двигательной системы, речи, ментальной сферы.
В 2018-м вышла версия 2.1. В UsabilityLab перевели новые пункты руководства.
Так что, чтобы прочитать все рекомендации, сначала смотрим документ по 1-й ссылке, затем — по 2-й.
Портфолио
Рекрутёр Дейв Фельдман рассказал, каким должно быть портфолио.
Дизайнеры занимаются украшением своей работы, и она становится сложной для восприятия. Часто это детальное описание процесса, который обычно не уникален.
Общий подход:
- Определите, кто будет пользоваться вашим портфолио, его особенности. Например, рекрутёр не может долго изучать каждого кандидата, он должен быстро отсеивать неподходящих;
- Подумайте, как показать отличия вашего проекта от проектов других дизайнеров, других ваших проектов, вашего обычного подхода. Иногда это процесс, но чаще — что сделано, почему и что вы узнали в процессе;
- Расскажите, почему ваше участие в проекте дало уникальный и интересный результат.
Описание проекта:
- Покажите макеты в полном размере, чтобы их можно было рассмотреть;
- Не используйте мокапы с изометрией и перспективой;
- Дайте краткий обзор процесса. Особенно, если новая информация привела к его корректировке;
- Дайте обзор проблемы и предметной области;
- Покажите, что сделали именно вы: с чего начали, что изменили, какие были ограничения, что вы хотели бы изменить. Изображения «до» и «после» очень ценны.
Список проектов:
- Представьтесь кратко и уникально;
- Оформление — либо стандартное, либо невероятно крутое;
- Подумайте, какая информация будет полезна в списке проектов: какую проблему решали, дата проекта, за что отвечали вы, тип работы;
- Лучше пара отличных проектов, чем много посредственных. Рекрутёр может посмотреть их все без ощущения, что он что-то упустил;
- Чтобы посетитель не тратил время, не делайте сложную навигацию и долгую анимацию.
(Самая популярная ссылка в этой подборке, если судить по количеству лайков в ВК.)
Ошибки продуктовых дизайнеров
Евген Ешану рассказал об основных ошибках продуктовых дизайнеров:
- Непонимание, как люди будут использовать продукт в реальной жизни;
- Убеждённость в их логичности;
- Вываливание на пользователя лишней информации. Ожидание, что он прочитает весь предложенный текст;
- Инновации ради инноваций;
- Изменение привычных паттернов взаимодействия при редизайне;
- Неспособность спрашивать, зачем делается продукт, какая задача таким образом решается и другие важные вопросы;
- Нежелание писать о продукте просто, для людей;
- Добавление большого количества не ключевых возможностей;
- Бездумная реализация пользовательских пожеланий;
- Привлечение многих людей к созданию продукта. Огромная команда не способствуют оригинальности;
- Убеждённость, что пользователь при взаимодействии с продуктом будет сосредоточен и сможет уделить ему достаточно времени;
- Добавление на дорожную карту функций вместо бизнес-проблем, которые надо решить;
- Отсутствие пользовательского тестирования;
- Ожидание от пользователя машинной точности при работе с интерфейсом;
- Моментальный переход к решению заявленной проблемы вместо попытки разобраться, правильная ли это проблема;
- Непонимание того, что человеческое мышление быстро не меняется. Что было трудным для пользователя 20 лет назад, продолжает быть трудным сегодня.
В реальности никто не протянет вам проблему в красивой и аккуратной упаковке. Её придётся обнаружить самому. Было бы слишком легко видеть только поверхностные изъяны и не копать глубже, чтобы решить настоящие проблемы.
Дон Норман
Дизайн данных
Павел Шерер написал серию статей про дизайн данных. Первая объясняет, что это (не инфографика и не информационная архитектура) и зачем им надо заниматься.
Дизайн данных — проектирование структуры, обмена и обработки данных, то есть:
- Планирование того, где и как будут храниться данные в вашем продукте, как они будут передаваться между компонентами и как в них обрабатываться;
- Решение, какую информацию гнать на сервер, какая прекрасно полежит на клиенте, а какой место только на сторонних сервисах.
Что делать, если пользователь изменил свой аватар, но прежний у кого-то ещё валяется в кэше? В какой момент и как нужно провести обновление устаревшей картинки? Вы уверены, что разработчики вообще подумают об этом? А даже подумав, не сделают это топорно, прямо на глазах у пользователя меняя одно изображение на другое? Вроде, банальность, но встречается повсеместно.
В Фейсбуке один из подписчиков раскритиковал подход, и возникло интересное обсуждение.
Таблицы для управления данными
Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).
В первой статье разбирается просмотр данных:
- Рабочая таблица должна занимать максимум места на экране. Как вариант — опция «на весь экран»;
- Объединяйте данные. Если есть данные о фамилии, имени и отчестве, их целесообразно вывести в один столбец ФИО. Должность или роль в системе тоже можно присоединить к ФИО;
- Бесконечная прокрутка и кнопка «Показать ещё» не подходят для отображения строк таблицы. Делайте постраничную навигацию. Это удобно и для коллективной работы с таблицей;
- Показывайте по умолчанию больше строк на одной странице: 50, 100, 500;
- Используйте цветовые индикаторы. Красить строку целиком стоит только при отклонении от нормы;
- При наличии цветовых индикаторов полезно отображать легенду цветов;
- Храните пользовательские настройки вида, не сбрасывайте их после окончания сеанса;
- Связанные сущности (название организации может быть связано с карточкой организации) полезно делать ссылками на соответствующие карточки. Но если таких сущностей в строке много, выделите только полезные в работе;
- Строка должна подсвечиваться при наведении курсора. Должна быть возможность выделить строку кликом на неё;
- Нет ничего страшного при появлении горизонтальной прокрутки;
- В некоторых случаях полезно маркировать просмотренные записи;
- Должна быть настройка отображения столбцов с системными свойствами (ID, дата создания, автор, дата изменения);
- Переход к просмотру записи удобно сделать по двойному клику;
- Иногда удобен режим предпросмотра, когда по клику открывается не вся запись, а сводка по ней, как в Google Drive.
Строка в таблице часто является прелюдией к просмотру полной информации по записи. На моей практике в 99% рабочих таблиц модальный режим просмотра уступал просмотру записи на отдельной странице.
Активное обсуждение в ВК.