Описание
Продукт
Роль
Product Designer
Даты работ
2025 - Настоящее время
Команда
Бэк (5)
Фронт (2)
Тестировщики (2)
Аналитики (4)
Руководитель проекта (1)
Владелец продукта (1)
Пользователи
Инженеры данных и геологи-эксперты с опытом работы с базами данных
Ключевая метрика
Целостность данных. Мы исключили риск накопления мусорных данных. Теперь пользователи не могут загрузить информацию, пока не утверждена жесткая структура модели
Контекст и проблема
О фиче
Визуальный конструктор, который позволяет пользователям самостоятельно проектировать структуру хранения данных. Они создают сущности, настраивают атрибуты и связи между ними без написания кода
Проблема
Изначально мы сделали ставку на хранение, а не на структуру. Проработали огромный модуль для импорта данных. А в итоге получили набор разрозненных таблиц, которые невозможно объединить/связать. Система превратилась в цифровой архив, с которым нельзя работать
Решение проблемы
Мы полностью перевернули процесс: сначала структура, потом наполнение. Теперь пользователь обязан сначала спроектировать и утвердить жесткую модель данных (каркас). Только после этого система разрешает загружать в нее информацию. Это гарантирует, что все данные изначально совместимы и легко связываются друг с другом
Бизнес-цель
Чтобы продукты платформы могли обмениваться информацией, они должны говорить на одном языке. Единая модель - это фундамент, который позволяет объединять данные из разных источников в общий граф и принимать решения на основе полной картины, а не фрагментов
Проблемы пользователей
Ручное сопоставление данных
Эксперты тратили часы на попытки понять, как связаны «Идентификатор скважины» из одного файла и «Well_Name» из другого. Им нужен был инструмент, который исключает эти конфликты еще на этапе проектирования
Моя задача
Найти оптимальное решение на вырост
Спроектировать гибкий интерфейс, устойчивый к изменениям бизнес-логики и масштабированию без переделок
Предпосылки: почему начали работать над фичей «Модели данных»
Процесс работы
Ключевая гипотеза
Гипотеза
Если дать пользователям инструмент для явного задания структуры данных до начала наполнения, то мы снизим количество ошибок, упростим согласование и обеспечим целостность данных при изменениях
Критерии успеха
Уменьшилось количество ошибок при загрузке и обновлении данных
Уменьшилось количество ручных проверок между версиями моделей
Увеличилась скорость согласования модели с экспертами
Увеличилось повторное использование моделей другими продуктами
Первые шаги
Анализ и поиск референсов
Я изучила интерфейсы традиционных СУБД, чтобы опираться на привычные ментальные модели инженеров данных. Но жёсткие ресурсные ограничения исключали полное копирование этих интерфейсов. Задача - найти баланс: привычная работа с данными + упрощённый нативный UI платформы
Стратегия: от сложного к простому
Я начала с самого нагруженного узла - страницы детального просмотра модели. Здесь пересекаются ключевые инструменты редактирования и визуализации связей - идеальная точка для проверки архитектуры интерфейса
Я опиралась на принципы и модели, знакомые пользователям по работе с СУБД, и переиспользовала их в интерфейсе продукта
Страница модели
Проблема
Модель данных может содержать сотни сущностей. Вывод всего контента сразу создает когнитивную перегрузку
Решение
Вложенная структура - основной список и детальная панель, которая появляется по выбору сущности. Контекст сохраняется, а фокус остаётся на актуальных данных. Это также обеспечило гибкость: новые параметры и табы можно добавлять без ломки лейаута
Результат
Такая структура прошла проверку масштабированием. Новые фичи бесшовно встраиваются в интерфейс, не ломая привычные сценарии. Благодаря чему, двигаемся дальше без дизайн-долга и глобальных переделок
Страница модели. Рабочая область разделена на три блока: слева - список сущностей (будущих таблиц), по центру - визуализация структуры и основные действия, справа - панель контекста с информацией о выбранном объекте. При отсутствии выделения отображаются данные всей модели.
Страница модели. Выделили сущность
Страница модели. Выделили связь
Список моделей. В текущей версии используются дефолтные обложки. Генерация динамических превью структуры заложена в бэклог
Версионирование и Diff
Проблема
Модель живая, она меняется. Как пользователю понять, что изменилось в версии 1.2.0 по сравнению с 1.1.0, чтобы не потерять данные при миграции
Решение
Визуальный режим сравнения, который выделяет добавленные, изменённые и удалённые атрибуты. Ручная сверка списков или JSON занимала бы часы - визуальный Diff сокращает процесс до минут
Результат
Пользователи без навыков SQL смогли быстро понять изменения через интерфейс
Флоу работы с версионированием структуры
Новая версия модели перешла в статус согласования изменений
Дата-инженер анализирует и применяет согласованные изменения
При необходимости пользователь может углубиться в детали, вплоть до SQL-запросов
Статусная модель
Проблема
После реализации флоу пользователи теряли контекст прогресса при работе с моделями данных
Решение
Полностью переработала статусы модели. Ушла от трансляции системных состояний к продуктовой логике: переработала 9 разрозненных статусов в 3 интуитивных бизнес-этапа
Результат
Интерфейс стал самодостаточным. Команда и новички считывают логику процесса моментально, не прибегая к спецификациям
К каждому статусу идет тултип, дающий пояснение на каком этапе находится модель, и кто над ней работает
Системность
и масштабируемость
Переиспользование паттернов
Я выбрала за референс паттерны интерфейса, похожие на Figma — это сэкономило время мне и разработчикам: мы переиспользовали базовую логику и добавили только продуктовые функции. Когда появлялись новые бизнес-требования, мы легко интегрировали их в существующую структуру без крупных изменений
Взаимодействие с командой
Параллельная работа
Я не стала ждать идеального ТЗ, а сразу пошла к разработчикам с черновиками. Мы обсуждали сложные моменты еще «на берегу». Благодаря чему разработчики понимали логику заранее, поэтому сделали фичу быстрее и без лишних правок
Двигались в слепую, но вместе
Требования постоянно менялись, поэтому я помогла команде разбить большую задачу на маленькие понятные куски. Мы выделили главное и отложили второстепенное. Результат Команда не перегорела и успела сдать рабочую версию в срок, несмотря на горящие дедлайны
Успешная работа над ошибками. Модель данных стала фундаментом для миграции. Мы реализовали механизм маппинга, который позволяет пользователям загружать существующие массивы информации и приводить их к стандартам платформы. Теперь даже старые данные проходят валидацию и встраиваются в новую жесткую структуру
Результаты и рефликсия
Бизнес-результаты
Подтверждение главной гипотезы
Мы изменили поведение пользователей: они перестали создавать «свалку» из таблиц и перешли к осознанному моделированию. Качество данных в системе выросло, так как теперь в систему попадает только то, что прошло проверку эксперт
Self-Service для экспертов
Мы убрали разработчиков из цепочки создания схем данных. Результат: Эксперты (геологи, аналитики) теперь сами проектируют и меняют структуру данных без написания ТЗ для IT-отдела. Это сократило цикл внесения изменений в модель с недель до часов.
Уменьшилось кол-во вопросов
На демонстрациях и при обучении новых сотрудников людям больше не нужно объяснять, в каком статусе находится модель и что делать дальше. Интерфейс стал говорить сам за себя
Ретроспектива
Сплоченность как ключ к результатам
Теперь я всегда подчеркиваю важность параллельной работы в тесном взаимодействии: регулярные обсуждения, общие обновления и прозрачность для всех. Это позволило нам оставаться на одной волне, быстро адаптироваться к изменениям и минимизировать доработки, превратив неопределенность в преимущество
От сложного к простому
Вместо того чтобы стартовать с легких сценариев, я теперь фокусируюсь на самых сложных. Если дизайн выдержит максимальную нагрузку, простые случаи соберутся автоматически, минимизируя риски и переделки