Партнёрский портал дистрибьютора, в котором закупочный список превращается в заказ без менеджера — поверх системы цен и остатков, которую нельзя было заменить.
Результат. Система отслеживает не каталог, а спецификацию. Строка сохраняет файл, номер, исходный текст и количество от импортированной таблицы до оформленного заказа. Цена решения: покупатель вручную разбирает каждую неоднозначную строку, потому что данные не позволяют подтвердить совместимость за него.
Дистрибьютор продаёт профессиональное видеонаблюдение системным интеграторам. Партнёры приходят не выбирать товар, а закупать по готовому списку для проекта с датой и договорными ценами. Портал при этом вёл себя как обычный магазин.
Аудит десяти экранов показал один паттерн: навигация без подписей, маркетинг перед рабочими задачами, десятки фильтров без поиска и выбранного количества, карточка без статуса корзины и возраста остатка.
По отдельности это не блокеры, но вместе любой нетривиальный шаг заканчивался сообщением персональному менеджеру. Условия партнёра жили у человека, а портал использовали перед тем, как ему написать.
Бриф просил современный интерфейс, но «найти товар и положить в корзину» — единица магазина, не работы покупателя.
Покупатель работает со спецификацией на 10–50 строк, которая уже существует в таблице, пересылается и правится вручную. Старый портал заставлял вводить её снова, а неоднозначность мог разрешить только человек.
Поэтому система должна хранить строку: откуда она пришла, что было написано и во что её сопоставили. Цены, склад, заказ и будущий спор о поставке должны уметь вернуться к источнику.
Провести готовую спецификацию до оформленного заказа, не потеряв ни одной исходной строки.
Единственным твёрдым доказательством был старый продукт, поэтому я начал с когнитивного прохода десяти экранов и шкалы тяжести, которая разделяет блокер и визуальную шероховатость. То, чего статичный экран не доказывал, отмечалось как «не подтверждено», а не как дефект.
Дальше — бриф с разделением фактов и целевых предположений, сценарии от пятистрочного повтора до импорта на двести строк и разбор шестнадцати сопоставимых экранов с решением «взять, адаптировать или отклонить».
Затем дизайн-система, двадцать экранов, React-прототип и каталог компонентов. Синтетический агент прошёл девять сценариев: 35 прогонов за три раунда. Именно сборка нашла то, чего ещё не хватало в экранах.
Сравнение с рынком должно проверить структуру до экранов и отделку после. Я сделал только вторую часть. Когда сравнил продукт с аналогами, уже были собраны четырнадцать экранов, и дешёвой точки для структурной находки не осталось.
Агентский прогон нашёл семь дефектов, два критических: фасетный фильтр ничего не фильтровал, у быстрого заказа не было первого состояния вставки, а стопка уведомлений могла перекрыть кнопку.
Две находки я сначала описал неверно. Проблемой была не позиция уведомления, а четыре карточки высотой 560 px; заказ открывался, но единственный вход назывался «Оплатить счёт». Исправление первоначальных диагнозов ничего бы не починило.
Двадцать четыре общих семейства и двадцать один доменный компонент. Общие взяты из открытой библиотеки только там, где были нужны экрану; таблицы закупки, строки разбора, цены, наличие, отгрузки и таймлайн принадлежат самому продукту.
Самая частая строка товара работает в каталоге и корзине через свойство контекста. Матрица намеренно неполная: у каталога нет disabled, а коммерческого изменения не бывает до добавления. Покрытие и отрисовку историй проверяют скрипты.
Числа проекта закрыты NDA и не публикуются; исходной точки для сравнения тоже нет. Метрики — план измерения, а не заявленный результат. Три из трёх — агентский прогон прототипа, не внедрение.
Большая его часть — компромиссы, а компромиссы стоит обсуждать.
Если кейс выше ответил на ваш вопрос — или добавил новый.
