Описание
Продукт
Роль
Product Designer
Даты работ
2023 - Настоящее время
Команда
Бэк (5)
Фронт (2)
Тестировщики (2)
Аналитики (4)
Руководитель проекта (1)
Владелец продукта (1)
Пользователи
Инженеры данных и геологи-эксперты с опытом работы с базами данных
Ключевая метрика
Рост экосистемы с 1 до 4 продуктов и переход на Self-Service: пользователи теперь самостоятельно настраивают поставку данных, не привлекая разработчиков
Контекст и проблема
О продукте
Nedra Data Platform - это платформа для управления жизненным циклом данных в нефтегазовой отрасли
Проблема
Нефтедобыча - это единая цепочка: данные разведки должны переходить в бурение, а оттуда - в моделирование. Но программы на каждом этапе свои и часто несовместимы. Инженерам приходилось вручную переносить данные между этапами, конвертируя форматы или вносить вручную
Решение проблемы
Платформа NDP становится единым хабом, который автоматически конвертирует данные и бесшовно передает их между продуктами
Бизнес-цель
Создать фундамент для масштабирования экосистемы. Единый стандарт заменяет дорогие кастомные интеграции и позволяет подключать новые продукты в разы быстрее.
Проблемы пользователей
Рутина и потери времени
Инженеры тратят часы на организацию поставки данных и перенастройку форматов
Ошибки
При ручном переносе теряются данные или ломается их структура
Фрагментация
Нет единого источника правды. Одни и те же данные хранятся в разных версиях локально
Моя задача
Настройка поставки данных
Разработать интерфейс для инженеров данных, который превратит сложную настройку интеграций и маппинга между разными продуктами в понятный процесс
Референсы: необходимо изучить и переиспользовать лучшие практики работы с данными
Процесс работы
Погружение
Специфика
Продукт требовал глубокого понимания архитектуры БД и API. Я изучала документацию вместе с аналитиками и разработчиками. Мой опыт работы с кодом сократил время на погружение и исключил технически нереализуемые идеи на старте
Проработка решений
Понимание потребностей юзеров
Исследования я проводила внутри команды. Чтобы превратить бизнес-требования в макеты, мы использовали формат воркшопов с PO, аналитиками, разработчиками и экспертами (потенциальные пользователи)
JTBD
Формировали «работы» инженера данных, чтобы понять, зачем ему конкретная фича
USM
Декомпозировали сложные флоу интеграций на пользовательские истории и расставляли приоритезацию
User Flow
Проектировала логические схемы перед отрисовкой макетов, чтобы найти ограничения на раннем этапе и быстро погрузить команду в контекст
Концепция: Nedra Data Platform объединяет данные вокруг физических объектов. Пользователи создают и импортируют объекты в нормативную модель, привязывают к ним расчёты, файлы и документы, а потребители находят нужную информацию через поиск или карту объектов
Пример использования фреймворков: Job Story
Пример использования фреймворков: User Flow
Ключевая гипотеза и решение
Фокус
Разделили работу с данными на три этапа: Прием, Преобразование и Поставка. В этом кейсе я работала над фундаментом - Приемом данных
Гипотеза
Если мы дадим инженерам прозрачный инструмент загрузки с автоматической валидацией, то платформа станет единственным достоверным источником. Пользователи перестанут хранить дубликаты локально, так как будут уверены, что в системе лежит самая свежая версия
Критерии успеха
Платформа NDP - первая точка поиска. При возникновении вопросов пользователь идет сразу в интерфейс, а не запрашивает файлы у коллег или в сетевых папках
Регулярные обновления. Пользователи сами поддерживают актуальность, регулярно загружая новые версии. Система не превращается в архив
Вариант А (не сработал)
Ожидание
В первой версии мы зеркально перенесли логику бэка в интерфейс. Мы предположили, что инженеры - мега эксперты, им нужен тотальный контроль над каждым параметром, и они во всем разберутся
Реальность
Порог входа оказался слишком высоким. В настройках путались даже сами разработчики. Нам пришлось написать инструкцию на 200 страниц, чтобы объяснить, как этим пользоваться. Это стало сигналом провала: если инструменту нужен такой мануал, значит, дизайн не работает
Загрузка файлов в специализированный источник данных: мы перенесли логику работы с пакетами, продиктованную разработчиками. Но потом сами же начали в ней путаться
Загрузка данных в источник данных потокового типа: писали подсказки и объяснения на языке дата-инженеров. Но пообщавшись и протестировав интерфейсы, поняли, что никто ничего не понял. Вопросов появилось только больше
Вариант Я (финальный)
Работа над ошибками
Я переработала подход, сместив фокус с функциональности на понятность и прозрачность процессов
Онбординг
Заменила внешние инструкции на встроенные подсказки и понятные названия полей
Результат
Теперь даже новичок может загрузить данные без помощи администратора и чтения мануалов
Детали
Как исправили ошибки
Анализ рынка показал, что у многих наших клиентов нет выделенных дата-инженеров. Эту работу выполняют смежные специалисты, знакомые с базами данных лишь поверхностно
Понизили порог входа
Мы снизили требования к квалификации пользователя. Интерфейс стал проводником, который страхует от ошибок, позволяя работать с системой сотрудникам с базовыми техническими навыками и знакомыми с базами данных
Таблицы как основа
Не стала изобретать велосипед, а адаптировала привычные паттерны СУБД. Это самый понятный способ работы с данными для нашей ЦА
Загрузка файлов в специализированный источник данных: я перенесла привычную массовую логику работы с файлами из Google Drive и Яндекс Диска в платформу, упростив интерфейс и сохранив знакомые пользователям паттерны поведения
Загрузка данных в источник данных потокового типа: вместо перегруженных требований в интерфейсе я предложила использовать файлы-примеры - пользователь может сразу увидеть корректный формат данных и либо адаптировать пример под себя
Импорт объектов в НСИ: пользователь сопоставляет атрибуты загружаемого файла с атрибутами справочника, а результат сразу видит в режиме предпросмотра
Карта объектов: просмотр объектов с геоданными
Поиск данных: юзер видит только доступные ему данные. Права доступа выдаются через панель администратора
Панель администрирования: мы спроектировали гибкий контур администрирования, позволяющий каждому продукту (системе) тонко настраивать права доступа к своим данным через роли и группы
Системность
и масштабируемость
Проектирование на вырост
Я не делаю дизайн ради одной фичи. Подключаюсь к обсуждению архитектуры на ранних этапах, чтобы понять горизонт планирования. Всегда проектирую с запасом. Это позволяет внедрять новый функционал бесшовно
Организация работы в Figma
За 3 года проект разросся до сотен экранов. Чтобы сохранить порядок, я внедрила модульную структуру: разделила монолит на логические файлы-модули с подробным описанием по каждому, чтобы команда могла быстро погружаться в контекст
Взаимодействие с командой
Ранняя валидация
Я подключаю разработчиков еще на этапе обсуждений и черновиков, чтобы сразу отсечь идеи, которые технически невозможны или делаются слишком долго и дорого
Баланс с бизнесом
Нахожу способы реализовать бизнес-задачи минимальными ресурсами. Переход от уникального дизайна к переиспользованию готовых паттернов ускоряет выход фичи в релиз в несколько раз
Дизайн ревью
Провожу ревью верстки перед релизом. Проверяю логику работы, отступы и состояние ошибок. Если реализация расходится с макетами или ломает сценарий — возвращаю задачу на доработку
Введение в контекст фичи на каждой странице Figma
Работа с переменными для ускорения изменений в макетах
Сценарный подход
Результаты и рефликсия
Бизнес-результаты
Масштабирование
Платформа выросла из «пилота» в экосистему. 4 ключевых продукта компании полностью интегрированы через нас
Снижение Support-нагрузки
Количество обращений сократилось. Большую часть ошибок валидации пользователи теперь решают самостоятельно через интерфейс
Автоматизация
Мы достигли автоматической синхронизации данных. Процесс стал фоновым
Ретроспектива
Ошибка в анализе ЦА
Мы понадеялись, что умные инженеры во всем разберутся, и сэкономили на исследованиях. Это привело к созданию слишком сложного интерфейса, который потом пришлось переделывать. Теперь я уделяю максимум времени анализу ЦА и глубинным интервью. Возвращаюсь к исследованиям не только на старте продукта, но и перед запуском каждой новой фичи
Стратегия важнее тактики
Вначале мы проектировал без понимания последующих шагов, из-за чего макеты пришлось выбросить через полгода. Но теперь при проектировании новых фич я всегда выясняю будущий вектор развития и сверяюсь с общим курсом продукта, чтобы закладывать гибкую архитектуру и избегать переделок
Инструкция - сигнал провала
Если для работы с интерфейсом нужно читать документацию - значит, дизайн не работает. Теперь я использую это как фильтр качества