Женя Шестаков

Обзор

Развитие внутренней платформы автоматизации операционных процессов ритейла.

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

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

Абстрактное представление эволюции дизайн-системы

Контекст

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

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

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

Проблема

Со временем продукт накопил UX-долг:

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

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

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

Моя роль

Я отвечал за переосмысление пользовательского опыта продукта и его дальнейшее развитие как масштабируемой дизайн-платформы.

UX-страя;
редизайн кор-системы пользовательского опыта;
создание дизайн-системы;
формирование UI-архитектуры;
взаимодействие с frontend-командой;
тестирование решений на реальных пользователях;
дальнейшая дизайн-эволюция продукта.

Процесс и решение

Сначала совместно с frontend-командой была согласована базовая логика UI-компонентов и тот подход, который будет использовать для создания дизайн-системы и кита в рамках кода.

Она создавалась не в вакууме, а на основе реальных пользовательских сценариев. Мы определяли ключевые флоу, я проектировали решения, выделял повторяющиеся паттерны и превращал их в компоненты.

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

Со временем это выросло в идею создания ALGA UI — унифицированной платформы компонентов для разных цифровых продуктов, использующихся внутри компании, работа над которой ведется до сих пор.

Результат

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

Проект позволил:

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

Абстрактно о метриках

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

Один из важных сторонних плюсов – ускорение дальнейшего проектирование нового функционала в рамках дизайн-процессов.

Карточки в инвенте: от гипотез к данным Многоролевое управление человеческими ресурсами Платформа управления операционными сценариями Корпоративные заказы: от оформления до выдачи

← вернуться на главную

Обзор

Проектирование и развитие пользовательского опыта учёта и инвентаризации. Многоитерационный подход в дизайне, быстрое внедрение и анализ фидбека пользователей.

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

Абстрактное представление пути принятия пользователем изменений во внутреннем приложении

Контекстt

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

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

Проблема

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

какие паттерны реально используются;
какие сценарии мешают;
какие интерфейсные решения стоит сохранять;
как улучшить UX без ломки привычного процесса.

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

Моя роль

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

В дальнейшем разработал новый дизайн карточки товара на основе полученных данных и с учётом нового запроса бизнеса.

Сравнение двух видов карточки в новом дизайне

Исследование и решение

Главной гипотезой для проверки была: пользователи практически не используют альтернативный вид отображения карточки товара.

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

Чтобы повысить достоверность данных, во вторую анкету была добавлена дополнительная двухступенчатая проверка согласованности ответов.

Это оказалось полезным решением — значительная часть респондентов не прошла проверку. Причины были разными: кто-то отвечал невнимательно, кто-то осознанно выбирал варианты, которые казались более правильными, а не отражали реальное поведение.

После фильтрации результатов оказалось, что около 65% пользователей действительно не используют альтернативный вертикальный режим отображения карточек.

Однако оставшиеся 35% продолжали активно работать с этим сценарием.

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

Результат

Получилось улучшить юзабилити критичных операционных сценариев и повысить удовлетворённость пользователей.

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

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

Абстрактно о метриках

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

Эволюция платформы автоматизации процессов ритейла Многоролевое управление человеческими ресурсами Платформа управления операционными сценариями Корпоративные заказы: от оформления до выдачи

← вернуться на главную

Обзор

Спроектировал многоролевую систему управления рабочими ресурсами.

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

Контекст

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

Упрощённое представление пути создания вакансии в системе

Проблема и вызов

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

Административные роли должны:

создавать потребности;
публиковать смены;
управлять доступностью;
контролировать заполнение.

Сотрудники должны:

видеть доступные предложения;
быстро понимать условия;
отслеживать свои активности;
понимать маршрут и рабочий статус.

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

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

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

Сотрудникам — понятный способ находить подходящие смены, оценивать условия и быстро принимать решение о выходе на работу.

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

Моя роль

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

Я проектировал систему целиком:

продуктовую архитектуру;
UX административных сценариев;
пользовательский опыт;
UX распределения ролей;
навигацию;
логику взаимодействия между ролями.

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

Решение

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

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

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

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

Результат

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

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

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

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

Абстрактно о метриках

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

Эволюция платформы автоматизации процессов ритейла Карточки в инвенте: от гипотез к данным Платформа управления операционными сценариями Корпоративные заказы: от оформления до выдачи

← вернуться на главную

Обзор

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

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

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

Управление операционными сценариями - Обзор

Контекст

На момент старта проекта компания использовала стороннее решение для управления рабочими задачами.

Несмотря на то, что система закрывала базовые бизнес-потребности, её развитие было ограничено внешними зависимостями. Любые изменения требовали длительного процесса согласований и доработок, а новые идеи и пользовательский фидбек невозможно было быстро превращать в новые фичи.

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

Проблема и вызов

Пользователи работают, не с абстрактными задачами, а с реальными операционные процессами:

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

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

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

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

Управление операционными сценариями - Проблема и вызов

Моя роль

Я проектировал продукт end-to-end:

продуктовую архитектуру;
UX административных сценариев;
UX исполнительских сценариев;
систему ролей и управления доступами;
интерфейсы создания задач;
интерфейсы контроля исполнения;
web и mobile UX;
сценарии учёта рабочего времени.

Интересный кейс

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

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

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

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

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

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

Процесс

Запуск платформы происходил итерационно.

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

Первые реакции были ожидаемо консервативными. Многие сотрудники привыкли к существующему инструменту и воспринимали изменения настороженно.

Однако по мере внедрения новых возможностей фокус обратной связи смещался от просьб вернуть старую систему к предложениям по развитию новой платформы.

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

Управление операционными сценариями - Процесс

Результат

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

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

Проект позволил:

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

Многоролевое управление человеческими ресурсами Корпоративные заказы: от оформления до выдачи Карточки товаров в инвентаризации: от гипотез к данным Эволюция платформы автоматизации процессов ритейла

← вернуться на главную

Контекст

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

Корпоративный заказ осуществляется по особым правилам:

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

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

Проблема и вызов

На первый взгляд в рамках основного МП корпоративный заказ мало отличается от обычного.

Пользователь также собирают корзину, также вводят количество и также нажимают кнопку Оформить заказ.

Однако за этим сценарием скрывается принципиально другой бизнес-процесс:

согласование заказа;
работа бухгалтерии;
подтверждение оплаты;
поставка товаров;
управление доступным ассортиментом;
другая подготовка заказа к выдаче.

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

Отдельным вызовом стало определение точки входа в корпоративный сценарий.

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

В результате был спроектирован отдельный корпоративный путь со своим каталогом и набором бизнес-правил.

Моя роль

Я проектировал сценарий end-to-end и участвовал в развитии функционала внутри нескольких продуктов внутри единой экосистемы:

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

Проектирование происходило одновременно для клиентской и операционной части продукта.

Интересный кейс

Одним из интересных наблюдений стало то, что корпоративные заказы далеко не всегда отличаются от обычных объёмом.

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

Процесс

Работа над продуктом требовала понимания всех участников процесса.

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

Создание заказа → согласование → оплата → поставка → сборка → контроль хранения → выдача.

При этом часть процессов оставалась за пределами пользовательского интерфейса и происходила через взаимодействие различных подразделений компании.

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

Результат

Проект позволил:

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

Для меня этот проект стал ценным опытом проектирования продукта на всём жизненном цикле сценария.

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

Особенно интересным оказался поиск баланса между развитием нового бизнес-направления и сохранением простоты существующей продуктовой экосистемы.

Абстрактно о метриках

Просадка в рамках основных заказов не случилось, а количество корпоративных выросло. Дополнительно стоит отметить, что постепенно удалось существенно снизить количество пользователей, которые случайно или намеренно попадали в корпоративные заказы и генерировали заказы, которые они не хотели оплачивать.

Эволюция платформы автоматизации процессов ритейла Карточки в инвенте: от гипотез к данным Многоролевое управление человеческими ресурсами Платформа управления операционными сценариями

← вернуться на главную

специализация

Кейсы

опыт работы в продуктовом дизайне

Бристоль Ритейл Логистикс

Рыбная мануфактура

Прайм

ранее

Обзор

Контекст

Проблема

Моя роль

Процесс и решение

Результат

Абстрактно о метриках

Другие кейсы

Обзор

Контекстt

Проблема

Моя роль

Исследование и решение

Результат

Абстрактно о метриках

Другие кейсы

Обзор

Контекст

Проблема и вызов

Моя роль

Решение

Результат

Абстрактно о метриках

Другие кейсы

Обзор

Контекст

Проблема и вызов

Моя роль

Интересный кейс

Процесс

Результат

Другие кейсы

Контекст

Проблема и вызов

Моя роль

Интересный кейс

Процесс

Результат

Абстрактно о метриках

Другие кейсы