NDA
DataFlow
Eastwind • B2B • data science-комбайн • 2023-2025
Некоторые из результатов
−82%
Сократил время разработки нового функционала на 82% за счет внедрения Material UI
+50%
Снизил количество обращений в поддержку через внедрение Feedbeak-функционала
↑42%
Повысил вовлечённость пользователей на 42% за счёт внедрения Model Train & Predict Job
до 6 задач за спринт
Построил систему согласования продуктовых решений (SPPTAU) по Agile, что позволило выпускать до 6 задач за спринт на одного дизайнера.
−60%
Сократил время на обработку датасетов на 60% благодаря автоматизации нейминга.
О проекте
Роль: Product Designer
Команда: Product Manager, Tech Lead, Product Designer, Backend Developer, Frontend Developer, QA Engineer, DevOps Engineer
Целевая аудитория:
Дата-сайентисты и аналитики
Маркетологи и продуктовые менеджеры
Телеком-операторы
Финансовые организации и ритейл
Фреймворки: JTBD, Ui/Ux-аудит, Ux-исследования, Качественные исследования
Результаты :
В числе задач
проектирование обработчика ML-моделей
разбиение CSV-файлов на партиции
интеграция с GitHub
улучшение работы с ML-ноутбуками
индексации и стейт-трекинг системы
визуализация через графы
ресурсные пресеты
автоматизация перезапуска data-сетов
Процесс работы над фичами
Каждая задача проходила одинаковый цикл по канбану — всего шесть стадий:
Scoping — общался с разработчиками и пользователями, поднимал боль, собирал вводные, делал прототипы. Иногда сразу обкатывал на юзабилити-тестах
Preview — презентовал прототип Team Lead разработки, обсуждали жизнеспособность решения
Presentation — показывал и защищал решение всей команде
Tuning — собирал правки, допиливал по итогам обсуждения
Analysis Done — презентовал пользователям и аналитикам, валидировали всё с продактом
UX Design — превращал всё в UX/UI-спецификацию для разработки и передавал в Assessment
——
Кейс:
Параллельное редактирование одного процесса (job), двумя пользователями
Проблема
Иногда возникает ситуация, когда первый пользователь отвлёкся и оставил job в процессе редактирования. Параллельно второй пользователь открывает тот же job и вносит изменения. При этом они не знают о действиях друг друга. Чтобы избежать конфликтов и потери правок, нужно уведомлять первого пользователя, что job был изменён другим участником.
Исследование
Провёл интервью с 7 активными пользователями: среди тех кто часто редактирует job, и часто фиксирует изменения после других. Выяснил, что у большинства был негативный опыт, когда они «случайно» перезаписывали чужие изменения — теряли время, приходилось выяснять, кто и что стер.
Выяснилось, что ~5–10 % редактирований происходят почти одновременно (в течение часа), что давало риски перезаписи.
Инсайты полученные в ходе интервью
Пользователи не хотят, чтобы изменение было запрещено — для многих блокировка мешает работе (например, когда job надо срочно подправить).
Но им важно понимать, что кто-то уже изменил — прежде чем продолжать — чтобы не «нарваться» на конфликт или потерю правок.
История правок и возможность дублирования job воспринимается как важный инструмент безопасности: пользователи чувствуют контроль над своими данными.
Гепотезы для новых задач (беклог)
Можно расширить систему: добавить автоматическое слияние (merge) — если изменения затрагивают разные поля, предложить объединить их, чтобы избежать дублирования.
Улучшить интерфейс: добавить визуальное отображение «работает сейчас другой» — когда B открыт job, A сразу видит, кто редактирует, и может предупредить.
Сценарий
Пользователь A находится в режиме редактирования job.
Пользователь B вносит изменения и сохраняет job в это время.
Решение
Когда пользователь A возвращается к редактированию job, система проверяет, изменилась ли версия — если да, показывает диалог примерно такого вида:
«В этот job были внесены изменения другим пользователем. Обновить job или продолжить с текущей версией?»
Итог реализации данного функционала
Количество случаев потери данных (перезапись чужих правок) снизились до нуля после запуска механизма предупреждений на 90 %
Количество повторных правок / переработок из-за конфликтов, уменьшилось кол-во откатов, правок после того как B перезаписал A на 85%
Возрасла пользовательская удовлетворённость, cущественное снижение жалоб, рост доверия системе
Уменьшение когнитивной нагрузки что привело к возрастанию скорости редактирования Job