82. Каким должно быть дизайнерское портфолио

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

Материалы Проектората

Чем отличаются иконки «палец вверх», «сердце», «закладка» и «звезда», и что каждая значит по мнению большинства пользователей?

Вспомнил примеры использования этих метафор в интерфейсах и поделился своим мнением:

  1. Они подходят, чтобы выделить объект в неком позитивном ключе: а) Мне нравится, что здесь написано; б) Это может мне пригодиться.
  2. Выбор конкретной метафоры зависит от общей функциональности продукта и его тематики.
  3. Обычно в одном интерфейсе не задействуют одновременно: закладки и звёздочки, сердечки и пальцы вверх.

Интересные статьи

Руководство по обеспечению доступности веб-контента — WCAG 2.0 — уже давно создали в W3C и перевели на русский.

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

В 2018-м вышла версия 2.1. В UsabilityLab перевели новые пункты руководства.

Так что, чтобы прочитать все рекомендации, сначала смотрим документ по 1-й ссылке, затем — по 2-й.

Рекрутёр Дейв Фельдман рассказал, каким должно быть портфолио.

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

Общий подход:

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

Описание проекта:

  • Покажите макеты в полном размере, чтобы их можно было рассмотреть.
  • Не используйте мокапы с изометрией и перспективой.
  • Дайте краткий обзор процесса. Особенно, если новая информация привела к его корректировке.
  • Дайте обзор проблемы и предметной области.
  • Покажите, что сделали именно вы: с чего начали, что изменили, какие были ограничения, что вы хотели бы изменить. Изображения «до» и «после» очень ценны.

Список проектов:

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

(Самая популярная ссылка в этой подборке, если судить по количеству лайков в UX Notes ВКонтакте.)

Евген Ешану рассказал об основных ошибках продуктовых дизайнеров:

  1. Непонимание, как люди будут использовать продукт в реальной жизни.
  2. Убеждённость в их логичности.
  3. Вываливание на пользователя лишней информации. Ожидание, что он прочитает весь предложенный текст.
  4. Инновации ради инноваций.
  5. Изменение привычных паттернов взаимодействия при редизайне.
  6. Неспособность спрашивать, зачем делается продукт, какая задача таким образом решается и другие важные вопросы.
  7. Нежелание писать о продукте просто, для людей.
  8. Добавление большого количества не ключевых возможностей.
  9. Бездумная реализация пользовательских пожеланий.
  10. Привлечение многих людей к созданию продукта. Огромная команда не способствуют оригинальности.
  11. Убеждённость, что пользователь при взаимодействии с продуктом будет сосредоточен и сможет уделить ему достаточно времени.
  12. Добавление на дорожную карту функций вместо бизнес-проблем, которые надо решить.
  13. Отсутствие пользовательского тестирования.
  14. Ожидание от пользователя машинной точности при работе с интерфейсом.
  15. Моментальный переход к решению заявленной проблемы вместо попытки разобраться, правильная ли это проблема.
  16. Непонимание того, что человеческое мышление быстро не меняется. Что было трудным для пользователя 20 лет назад, продолжает быть трудным сегодня.

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

Павел Шерер написал серию статей про дизайн данных. Первая объясняет, что это (не инфографика и не информационная архитектура) и зачем им надо заниматься.

Дизайн данных — проектирование структуры, обмена и обработки данных, то есть:

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

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

В Фейсбуке один из подписчиков раскритиковал подход, и возникло интересное обсуждение.

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

В первой статье разбирается просмотр данных:

  1. Рабочая таблица должна занимать максимум места на экране. Как вариант — опция «на весь экран».
  2. Объединяйте данные. Если есть данные о фамилии, имени и отчестве, их целесообразно вывести в один столбец ФИО. Должность или роль в системе тоже можно присоединить к ФИО.
  3. Бесконечная прокрутка и кнопка «Показать ещё» не подходят для отображения строк таблицы. Делайте постраничную навигацию. Это удобно и для коллективной работы с таблицей.
  4. Показывайте по умолчанию больше строк на одной странице: 50, 100, 500.
  5. Используйте цветовые индикаторы. Красить строку целиком стоит только при отклонении от нормы.
  6. При наличии цветовых индикаторов полезно отображать легенду цветов.
  7. Храните пользовательские настройки вида, не сбрасывайте их после окончания сеанса.
  8. Связанные сущности (название организации может быть связано с карточкой организации) полезно делать ссылками на соответствующие карточки. Но если таких сущностей в строке много, выделите только полезные в работе.
  9. Строка должна подсвечиваться при наведении курсора. Должна быть возможность выделить строку кликом на неё.
  10. Нет ничего страшного при появлении горизонтальной прокрутки.
  11. В некоторых случаях полезно маркировать просмотренные записи.
  12. Должна быть настройка отображения столбцов с системными свойствами (ID, дата создания, автор, дата изменения).
  13. Переход к просмотру записи удобно сделать по двойному клику.
  14. Иногда удобен режим предпросмотра, когда по клику открывается не вся запись, а сводка по ней, как в Google Drive.

«Строка в таблице часто является прелюдией к просмотру полной информации по записи. На моей практике в 99% рабочих таблиц модальный режим просмотра уступал просмотру записи на отдельной странице».

Этот материал стали активно обсуждать уже во ВКонтакте. Присоединяйтесь ;)

Рассылка Проектората × UX Notes

Технологии цифрового маркетинга — книга, где я был соавтором (параграф про создание сайта) и литературным редактором (привёл текст к единой стилистике и упростил формулировки). От 250 рублей.