Интерфейс канбан-доски: создаём набор компонентов в Pixso

Продуманный интерфейс канбан-доски — это система повторно используемых состояний, а не просто ряд разноцветных колонок. Карточкам нужен единый набор метаданных, колонкам — понятные ограничения и пустые состояния, а перетаскиванию — определённое поведение до, во время и после перемещения. В этом руководстве мы соберём в Pixso редактируемый набор канбан-компонентов для продуктовой команды, в которой задачи проходят этапы «Бэклог», «В работе», «На проверке» и «Готово».

Часть 1. Определите модель доски до отрисовки карточек

Сначала запишите правила рабочего процесса. В нашем примере на доске четыре колонки, у задачи может быть один исполнитель, отображаются один приоритет и не более двух меток, а колонка «В работе» вмещает до трёх карточек. Чтобы перенести карточку в «На проверке», нужно назначить исполнителя. Завершённые карточки показывают дату выполнения вместо срока.

Это правила конкретного примера, а не универсальные требования канбана. Уточните у владельца продукта:

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

Храните эти правила рядом с макетом. В Pixso Whiteboard можно разместить предварительную схему процесса или таблицу требований PRD, а в дизайн-файле — редактируемую доску и состояния компонентов. Доска не определяет правила: она делает их видимыми для обсуждения.

Перенесите согласованные правила процесса на доску с четырьмя колонками из примера ниже: «Бэклог», «В работе», «На проверке» и «Готово». Перед созданием повторно используемых компонентов проверьте, соответствуют ли ограничения незавершённой работы (WIP), поля карточек и пустое состояние правилам вашей команды.

Часть 2. Спроектируйте структуру карточки

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

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

Соблюдайте предсказуемый порядок информации:

1. Идентификатор задачи и обозначение статуса.
2. Название задачи с переносом на заранее определённое число строк.
3. Метки области продукта или типа работы.
4. Приоритет и предупреждение о сроке, когда требуется действие.
5. Исполнитель и дополнительные счётчики.

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

Часть 3. Соберите компонент карточки в Pixso

В Pixso создайте страницу «Канбан-компоненты» и раздел для исходных компонентов. Настройте компоновку карточки так, чтобы заголовок, метки и метаданные адаптировались к реальному содержимому. Преобразуйте структуру в компонент и предоставьте свойства, которые команда действительно меняет.

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

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

Часть 4. Создайте колонку и её состояния

Компоненту колонки нужны заголовок, счётчик, необязательный лимит, список карточек, действие добавления и пустое состояние. Стабильная ширина должна позволять просматривать карточки, а горизонтальным переполнением должна управлять доска. Показывайте лимит незавершённой работы как «2/3», а не только меняйте цвет при его достижении.

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

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

Часть 5. Соберите интерфейс канбан-доски

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

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

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

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

Часть 6. Представьте перетаскивание как последовательность состояний

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

1. Ожидание: карточка читается, а элемент захвата не конкурирует со ссылками и меню.
2. Захват: исходное место остаётся понятным, а перемещаемая карточка визуально приподнята.
3. Над допустимым назначением: маркер вставки точно показывает, куда попадёт карточка.
4. Над недопустимым назначением: область назначения объясняет правило, например: «Назначьте исполнителя перед отправкой на проверку».
5. После отпускания: карточка появляется на новом месте, и доска подтверждает смену статуса.
6. Сбой: карточка возвращается или остаётся доступной для восстановления; показаны причина и способ повторить действие.

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

Часть 7. Предусмотрите перемещение без перетаскивания

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

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

Часть 8. Настройте фильтры, сохранив понятное состояние доски

Фильтры меняют видимое содержимое, а не сам рабочий процесс. Показывайте активные фильтры и понятное действие сброса. У счётчиков колонок должен быть определённый смысл: все карточки или только видимые. Для видимых результатов рассмотрите формат «2 из 8», чтобы отфильтрованную доску не приняли за потерю задач.

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

Часть 9. Обсудите набор компонентов с командой

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

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

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

Часть 10. Подготовьте доску к разработке

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

Режим просмотра для разработчиков и D2C в Pixso помогают при передаче дизайна, в том числе в сценариях генерации кода для React, Vue, HTML, ArkUI и Flutter. Разработчикам всё равно необходимо проверить сгенерированный код: модель состояний проекта, библиотеку перетаскивания, семантику, управление с клавиатуры, производительность, синхронизацию данных и тесты. Актуальный процесс описан в руководстве Pixso по D2C.

Часть 11. Чек-лист интерфейса канбан-доски

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

Итоги

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