Конкурсное техническое задание на реализацию прототипов рабочей области (Kanban) CRM

1. Назначение документа

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

В данном документе будут описаны следующие элементы интерфейса:

1. Рабочая область - Kanban-доска для запросов от клиентов (Requests) и задач (Tasks) связанных с запросами.

2. Сущность request на доске

3. Сущность task на доске

4. Раскрытая сущность request

5. Раскрытая сущность task

6. Фильтры и настройки рабочей области

В рамках конкурса необходимо реализовать 4 экрана:

1. Экран канбан-доски в режиме "Requests"

2. Экран канбан-доски в режиме "Tasks"

3. Экран просмотра карточки запроса

4. Экран просмотра карточки задачи

Для общего представления структуры проекта рекомендуется ознакомиться с диаграммой: Figma.

2. Требования к интерфейсу Kanban-доски

Рабочая область CRM Modular реализована в формате канбан-доски с возможностью переключения между двумя основными режимами отображения:

1. Requests (запросы - входящие обращения от клиентов).

2. Tasks (задачи - конкретные действия, выполняемые по запросам, но задачи могут быть и не привязаны к запросам).

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

2.1 Основные элементы Kanban-доски

2.1.1 Колонки 

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

В режиме "Requests":

• New – все поступившие обращения клиентов.

• In progress – запросы, взятые в работу.

• Assigned to Work – запросы, переданные на исполнение в виде задач.

• Closed – выполненные или отмененные запросы.

В режиме "Tasks":

• Planned – задачи, поставленные, но еще не начатые.

• In progress – активные задачи, выполняемые сотрудниками.

• Pending Review – задачи, ожидающие подтверждения.

• Completed – выполненные задачи.

• Canceled – задачи, которые не были выполнены по различным причинам.

2.1.2 Сущность REQUEST на доске

В режиме "Requests" важно отобразить всю необходимую информацию по запросам от клиентов, данная доска служит для контроля работы над запросами. Предлагается Requests выполнить в формате карточки (классические задачи в Kanban).

Атрибуты сущности request в режиме "Requests":

• Request ID (присваивается системой).

• Date of creation (присваивается системой).

• Potential amount (присваивается системой или вручную).

• Client (Имя + аватар) (присваивается системой или вручную).

• Source (выпадающий список, источник откуда пришел запрос: web-form, call, messenger etc.).

• Executor (аватар, при наведении на аватар отображаем Имя исполнителя).

• Call-icon (при клике на которую, пользователь может позвонить по запросу клиенту)

• Icon with number of tasks (цель показать сколько открытых задач по данному запросу) (возможно, стоит подумать над возможностью функционально раскрывать requests и посмотреть связанные с ним tasks).

В режиме "Tasks" важно отобразить все задачи связанные с запросами. В интерфейсе необходимо сгруппировать задачи по запросам наглядным образом.

Атрибуты сущности request в режиме "Tasks":

• Request ID.

• Potential amount

• Client (name + avatar).

2.1.3 Сущность TASK на доске

В режиме "Requests" задачи должны отображать только иконкой с их количеством у запроса, либо при помощи механики, которая позволит раскрыть запрос и отобразить связанные с ним задачи.

Атрибуты сущности task в режиме "Requests":

В режиме "Tasks" важно отобразить все задачи связанные с запросами. В интерфейсе необходимо отразить принадлежность задачи к запросу.

Атрибуты сущности task в режиме "Tasks":

• Task ID.

• Title.

• Executors (может быть несколько исполнителей, аватарки, при наведении на аватарки отображаем Имя исполнителя).

• Deadline.

• Priority.

2.1.4 Раскрытая сущность REQUEST

При клике на Request ID или на карточку запроса на Kanban-доске в режиме "Requests" пользователю доступна полная информация по сущности REQUEST. Сущность должна быть логически и визуально поделена на основные блоки:

1. Details (детальная информация по запросу)

   1. Request ID.

   2. Title.

   3. Description.

   4. Date of creation.

   5. Potential value.

   6. Source (источник откуда пришел запрос: web-form, call, messenger etc.).

   7. Executor (Имя + аватар).

   8. Status

2. Client (детальная информация по клиенту + может быть информация о компании)

   1. Name client (avatar + name)

   2. Phone

   3. Email

   4. Address of client

   5. Name of company (если есть компания)

3. Notes (поле для внесения заметок по запросу)

4. Todo (место, где мы можем планировать взаимодействие по запросу: call, chat, email)

5. New task (кнопка, при нажатии на которую пользователи попадают в форму создания задачи, задача связаны с запросом из которого была вызвана форма)

6. History (место, где отображаются notes, todo и tasks по данному запросу)

2.1.4 Раскрытая сущность TASK

При клике на Task ID или на карточку задачи на Kanban-доске в режиме "Tasks" пользователю доступна полная информация по сущности TASK.
Сущность должна быть логически и визуально поделена на основные блоки:

1.  Details (детальная информация по задаче)

   1. Task ID.

   2. Title.

   3. Description.

   4. Date of creation.

   5. Deadline

   6. Priority

   7. Estimated time (запланированное время на закрытие задачи)

   8. Executors (Исполнители, имя + аватар).

   9. Status

   10. Related request (Request который связан с задачей с возможностью перейти к запросу)

2. Client (детальная информация по клиенту + может быть информация о компании)

   1. Name client (avatar + name)

   2. Phone

   3. Email

   4. Address of client

   5. Name of company (если есть компания)

3. Notes (поле для внесения заметок по задаче)

4. ToDo (место, где мы можем планировать взаимодействие по запросу: call, chat, email)

5. Attachments (место, где хранятся файлы по задаче)

6. History (место, где отображаются notes, activities и attachments по данному запросу)

2.1.5 Фильтры и настройки рабочей области

Общие фильтры и настройки для двух режимов отображения Kanban-доски:

1. Переключатель между режимами: Request mode & Task mode

2. Фильтрация по исполнителям

3. Поиск по Request ID/Task ID, Name Client.

4. Быстрое переключение между своими и общими задачами

5. Сортировки сущностей (по умолчанию сортировка по Date of creation, возможно поменять на Potential amount или Priority)

6. Кнопка переключения в табличный вид (функционал таблиц будет описан в другом документе)

3. Функциональные возможности Kanban-доски

3.1. Переключение между режимами "Requests" и "Tasks"

• Меняется состав колонок, а также логика группировки карточек.

• В режиме "Requests" основное внимание уделяется контролю за обращениями клиентов.

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

3.2. Иконка шестеренки с настройками

Для пользователя с расширенными возможностями отображаем шестеренку с настройками доски (в дизайне только отобразить иконку с настройками, функционал с кастомизациями будет описан в другом документе):

• Возможность изменять наименование столбцов и добавлять/удалять их.

• Возможность настройки автоматизации.

• Возможность настройки бизнес-процессов.

3.3. Работа с карточками

• Возможность перетаскивания карточек между колонками.

• Взаимосвязь запросов и задач:

  • Из запроса можно сразу создать задачу.

  • У задачи отображается связанный запрос.

• Назначение ответственных.

4. Требования к визуальному оформлению

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

4.1. Общие принципы визуального оформления

Чистота и минимализм

• Пространство: Дизайн должен быть воздушным, с достаточными отступами между элементами, чтобы не перегружать интерфейс.

• Минимум визуального шума: Использование только необходимых элементов без избыточных деталей, которые могут отвлекать от основной работы.

• Единообразие: Стиль оформления должен быть единым во всей системе, чтобы избежать разрозненного восприятия.

Читаемость и удобство восприятия

• Контрастность: Текст и интерфейсные элементы должны быть хорошо различимыми (оптимальное сочетание фона и текста).

• Типографика:

  • Использование читаемых шрифтов без засечек (например, Inter, Roboto, Open Sans).

  • Размер шрифта достаточный для комфортного чтения, особенно для ключевых данных.

  • Различные уровни заголовков и акцентные элементы должны иметь размерную и цветовую иерархию.

• Интуитивное считывание данных:

  • Важная информация (статусы, дедлайны, ответственные) должна быть визуально выделена, но не агрессивно.

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

4.2. Визуальные элементы интерфейса

Канбан-доска

• Карточки должны быть четко структурированы, не перегружены текстом, но содержать все нужные данные.

• Гибкая ширина карточек – адаптация размера в зависимости от количества информации.

• Акцентные метки для приоритетов (например, цветовые индикаторы для приоритетов).

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