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

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

Предисловие

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

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

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

Начнём с максимально примитивной заготовки. Вот она:

Этап 1. Делим дни по типам

Сразу же учтём простой нюанс. Не все знают, что в США и Великобритании неделя начинается с воскресенья. Нужно обязательно показать это в макете и указать в спецификации для разработчиков:

Слева — календарь для России, справа — вариант для США и Великобритании

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

Наши пользователи просили добавить ещё и нерабочие занятые дни. Чаще всего это дни, когда сотрудник уехал в командировку, выступает на конференции или гуляет на корпоративе. Формально человек потратил время на рабочие обязанности, но для команды его ресурсы были недоступны.

Что ж, превращаем последнюю пятницу месяца (25 марта) в занятый день — корпоратив:

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

С типами дней закончили. Двигаемся дальше.

Этап 2. Добавляем точку отсчёта

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

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

Судя по календарю, сегодня 11 марта. Мы сомневались в этом визуальном решении, по пользователи быстро к нему привыкли

В некоторых случаях нам придётся блокировать прошедшие дни — например, когда пользователь выбирает дату для zoom-митинга. Мы ведь не можем назначить митинг на вчера, верно?

Прошедшие дни недоступны для выбора

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

Теперь давайте подумаем, как пользователи будут взаимодействовать с компонентом.

Этап 3. Проектируем взаимодействия

Наводим на даты

Как поведёт себя ячейка календаря, если мы наведём курсор на сегодняший день? А на будущий? Создаём общий стиль для обоих случаев:

Слева hover-состояние для сегодняшнего дня, справа — для будущего

Пользователь может навести курсор и на недоступные дни. Тогда лучше не молчать, а объяснить ему, почему он не сможет выбрать данную дату:

Выбор дат

А как пользователь будет выбирать нужный ему день? Это достаточно просто:

Пользователь выбрал 15 марта

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

Пользователь собирается делать задачу 4 дня

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

Из шестнадцати выделенных дней пользователь сможет посвятить задаче только одиннадцать

В выбранный период может так же попасть сегодняшний день (11 марта). Для него тоже придётся использовать отдельный стиль:

Думаете, это всё? Как бы не так! Пользователь может выделить период, а затем наводить на выделенные дни мышкой. Например, чтобы понять, почему некоторые из них «подсвечены белыми кружочками».

И нам обязательно нужно это объяснить:

Этап 4. Презентуем разработчикам. Обтекаем

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

Вот пара вопросов, которые нанесут серьёзный урон вашей репутации продумана.

А что если сегодняшний день — выходной?

Действительно, мы забыли добавить ещё один стиль для таких случаев:

Сегодня суббота, 12 марта. Пожалуйста, отдохните

Не успели мы ответить на первый вопрос, как руку тянет Principal Java Developer:

«А что если пользователя попросили поработать в выходные? Как ему затрекать время?»

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

Этап 5. Испытываем компонент

Отмучавшись два-три PBR-а и поправив все неучтённые кейсы, пора примерять наш компонент на самые разные ситуации. Зачем? Всё просто: компонент должен быть универсальным и обладать запасом гибкости.

Например, представьте, что ваш календарь будут использовать координаторы для покупки авиабилетов сотрудникам. В первом календаре координатор указывает дату вылета. В втором — дату возвращения. Вернуться раньше, чем улететь человек не может. Значит, наш календарь теоретически должен уметь передавать данные вовне:

А вот пример для бронирования корпоративной квартиры. Прошлые дни недоступны. Ближайшие 10 дней заняты. Заселиться можно только с 21 марта:

Теоретически можно объединить недоступные дни в колбаску-период, но лучше добавлять функции только когда они реально потребуются

Вы ещё живы?

Зря. Потому что мы не проработали и половины нюансов. Дизайнеру компонентов предстоит продумать как минимум:

• Выделение периодов длиной несколько месяцев (например, 1.01 – 1.05)
• Цветовой контраст элементов для пользователей с нарушениями зрения (не все различают цвета корректно)
• Клавиатурную навигацию для людей с ограниченными возможностями (не все могут кликать мышкой)
• Позиционирование календаря (куда ему выпадать, если снизу не хватает места?)
• Отображение календаря на экранах мобильных
• Выделение дат пальцем, а не курсором

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

Так что, ребята, берегите продуктовых дизайнеров. Они седеют ради вашего удобства.