B2B‑закупки: проектирование платформы для управления тендерами

Платформа: веб, от 1920 до 320 px.

Контекст: ревью, которое превратилось в редизайн

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

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

Этап 1. Дизайн-ревью

Ревью шло по трём слоям — от целого к деталям.

1. Сценарии. Ключевые пути обеих ролей от регистрации до сделки: где путь обрывается или требует догадки.

2. Эвристики и консистентность. Видимость статуса, предотвращение ошибок, единый язык и повторяемость паттернов.

3. Готовность к разработке. Состояния, пустые экраны, ошибки, адаптив — всё, что разработчик иначе придумает сам.

Главные выводы ревью:

• Нет модели ролей. Экраны не различали заказчика, поставщика, участника и гостя.
• Нет стадий. Приём заявок, ожидание торгов, торги и завершение выглядели как один и тот же экран с другим текстом.
• Не описаны развилки. Что, если заявок нет? Если одобрена только одна? Если поставщик не заполнил профиль?
• Форма создания тендера — одним полотном. Условия оплаты и поставки терялись среди десятков полей.
• Нет системы. Компоненты рисовались под каждый экран, адаптива не было.

Этап 2. Исследование

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

Конкурентный анализ тендерных и аукционных площадок: как они показывают статус, как устроена подача заявки, что происходит в момент торгов.

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

Стадия	Заказчик	Поставщик
Приём заявок	Приглашает, рассматривает заявки, запрашивает документы	Изучает условия, подаёт или отзывает заявку
Ожидание торгов	Видит допущенных участников	Настраивает автоставку
Торги	Наблюдает за ходом	Делает ставки на понижение
Завершение	Подтверждает победителя, оформляет сделку	Видит результат: победа или проигрыш
Отмена / не состоялся	Выбирает причину	Получает уведомление с объяснением

Этап 3. Архитектура и сценарии

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

Сценарии описаны отдельно для заказчика и поставщика, а развилки — как самостоятельные экраны, а не примечания на полях:

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

Swimlane: кто что делает и когда

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

Схему можно двигать и приближать прямо здесь.

Ключевые решения

1. Главная меняется вместе с пользователем

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

2. Каталог отвечает на вопрос «стоит ли открывать»

В карточке тендера — статус со сроком, обратный отсчёт, начальная цена с НДС и без, число позиций и участников. Отдельная строка объясняет, почему тендер показан именно вам: «4 из 7 компетенций вашей компании», «Подходит вашей специализации».

3. Создание тендера — четыре шага и предпросмотр

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

Шаг 1. Предмет тендера. Название, сроки и позиции. Форма сама считает, сколько дней пройдёт между окончанием приёма заявок и торгами, и предупреждает, что необработанные заявки будут отклонены автоматически. Товары и услуги добавляются по одному — прямо в форме, без модальных окон.

Импорт позиций. Тендер на восемьдесят позиций вручную не заполняют. Список загружается из CSV или Excel по готовому шаблону; ошибка формата и ошибка в таблице — отдельные состояния с объяснением, что исправить.

Шаг 2. Условия оплаты. Сложные условия собираются из простых выборов: тип оплаты, размер аванса, событие, после которого он выплачивается. Выбор типа раскрывает только те поля, которые к нему относятся.

Шаг 3. Условия поставки. Доставка или самовывоз, адрес из профиля компании или новый — его можно добавить, не выходя из формы. Срок задаётся датой или количеством дней.

Шаг 4. Требования к поставщикам. Кого допускать — только плательщиков НДС или всех — и почему это важно: предупреждение объясняет, как выбор повлияет на сравнение цен. Требования можно описать текстом или приложить документом. Дальше — предпросмотр тендера глазами поставщика.

4. Заявки — рабочий стол заказчика

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

5. Торги: всё важное остаётся на экране

Во время торгов у участника есть три вопроса: сколько времени на ход, какая сейчас цена и где в ленте мои ставки. Таймер, текущая ставка, шаг и номер участника собраны в одном блоке над лентой; собственные ставки подсвечены, новая — помечена. Участники анонимны — у каждого только номер.

Ставка — в два касания. Сумма уже рассчитана с учётом шага, остаётся подтвердить. Таймер хода продублирован в окне, чтобы не закрывать его ради проверки времени.

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

Когда лента становится длинной, блок с таймером и действиями закрепляется вверху: автоставку можно изменить или отменить, не прокручивая страницу назад.

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

6. Письма — часть сценария

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

Система и передача в разработку

Библиотека компонентов — типографика, кнопки, поля, карточки, статусы — собрана до детальных экранов, поэтому новые разделы складывались из готового.

Семь ширин: 1920, 1600, 1440, 1280, 1024, 768 и мобильная версия. Адаптив нарисован для каждого ключевого экрана, включая торги.

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

Результат

Платформа спроектирована целиком: регистрация и профиль компании, создание тендера, каталог, страница тендера во всех ролях и стадиях, заявки, торги с автоставкой, закупки, календарь, поддержка и письма.

Что было сложно

Одна сущность — много лиц. Страница тендера легко превращается в набор условий «если роль такая и стадия такая». Спасла таблица состояний: сначала договорились о ней, потом рисовали.

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

Скриншоты — из макетов на демонстрационных данных.