Satellite
Демо-продукт для международной выставки, который показывает работу спутниковой группировки без профильной подготовки.
cover.png
Коротко
О компании
Sofikom — внутренний стартап, который умеет считать баллистику и вести группировки космических аппаратов. Проблема в том, что эта экспертиза выглядит как формулы, координаты и таблицы — то есть никак не выглядит для человека, который не работает в отрасли.
Контекст
Стейкхолдер поставил задачу: к международной выставке сделать работающее демо, которое показывает технологические возможности компании вживую, на стенде, а не в презентации.
Задача
Задача была коммерческой, а не пользовательской. Реального заказчика и сформированных сценариев не существовало — продукт проектировался на опережение. Продуктовую логику и функциональные требования задавали аналитик и стейкхолдер, моя зона ответственности начиналась там, где требования нужно было превратить в интерфейс.
Двойное ограничение, которое определило почти все решения: интерфейс должен считываться за пару минут человеком без подготовки — и при этом быть реализуемым силами одной frontend-разработчицы за четыре месяца, на технологии, новой и для неё тоже.
Что сделала
- Собрала визуальный язык продукта с нуля — тёмная тема, стилистика глобуса, цветовое кодирование состояний, отрисовка траекторий — оттолкнувшись от разбора существующих спутниковых трекеров
- Спроектировала не только идеальные экраны, но и состояния, ошибки, поведение при наложении меток и проекций друг на друга
- Держала дизайн в границах реализуемого: сокращала сложную графику под срок, производительность отрисовки орбит и зон и ресурс одного фронтенд-разработчика
- Адаптировала дизайн-систему Sofikom под тип контента, которого в ней не было — карта, слои, объекты и состояния на глобусе
Роль и команда
Продуктовую логику вели аналитик и стейкхолдер, за корректность траекторий отвечал математик, за реализацию — frontend-разработчица. Я отвечала за визуальный язык продукта, UX/UI всех экранов, состояния и ошибки. Около 4 месяцев, жёсткий дедлайн под выставку.
Результат
Демо было реализовано в коде и работало на стенде международной выставки. На его основе аналитик собрал презентационное видео с демонстрацией экранов — компания использует его для дальнейших презентаций продукта.
Количественных метрик у меня нет: я была на выставке как наблюдатель, не участвовала в переговорах с посетителями и не имела доступа к коммерческим результатам. Не хочу подменять это оценочными формулировками.
Подробнее о процессе
Что компания продавала и почему это было трудно продать
Расчёт орбит, зон покрытия и ограничений по зонам — это инженерная работа, результат которой существует в виде чисел. Числа не продают: человек, который решает, работать ли с компанией, смотрит на таблицу координат и не видит там ни возможностей системы, ни уровня команды.
Отсюда и родился запрос стейкхолдера: нужен не документ и не презентация, а работающий продукт, в котором видно, что компания умеет. Выставка задавала и формат, и дедлайн — стенд, пара минут на посетителя, никакой возможности объяснять контекст заранее.
Кто на самом деле смотрит демо
Сам продукт в перспективе предназначен инженерам управления КА. Но демо на стенде смотрит не инженер, а потенциальный заказчик, который оценивает компанию. Это разные требования: инженеру нужна плотность данных и точность, посетителю стенда — чтобы за две минуты стало понятно, что происходит на экране и почему это сложно сделать.
Я проектировала под второго. Это решение объясняет почти всё остальное в кейсе: почему интерфейс намеренно разрежен, почему состояние аппарата кодируется цветом, а не строкой в таблице, и почему движение важнее числовой точности.
audience-engineer.png
audience-visitor.png
Простая схема на два столбца — «инженер: точность, плотность, полнота» / «посетитель стенда: понятность за 2 минуты, эффект, доверие». Показывает, что выбор аудитории был осознанным.
Оговорюсь честно: я не знаю, кто именно подходил к стенду и какие вопросы задавал. На выставке я была, но в общении с посетителями не участвовала. Портрет аудитории у меня рабочий, а не подтверждённый наблюдением.
Моя роль и её границы
Проект был устроен так: запрос шёл от стейкхолдера, продуктовую логику и функциональные требования формировал аналитик вместе с ним, математик отвечал за корректность траекторий, frontend-разработчица — за реализацию.
Что определяла не я: необходимость двух режимов отображения, набор функциональности — поиск, зоны покрытия, покрытие в точке, запретные зоны, работа со временем. Эти требования приходили сверху.
Что делала я:
- визуальный язык продукта целиком — тёмная тема, стилистика и цвет глобуса, оформление карты, визуальное представление траекторий;
- UX/UI всех экранов: как устроено взаимодействие внутри экрана, что происходит при выборе объекта, как ведут себя панели;
- состояния и ошибки, включая поведение при наложении объектов друг на друга;
- адаптацию дизайн-системы Sofikom под новый для неё тип контента;
- постоянную сверку решений с возможностями фронтенда — чтобы то, что нарисовано, было сделано в срок.
Разделение важно: продуктовую логику здесь вёл аналитик, а я отвечала за то, чтобы эта логика стала считываемой. Это и был мой вклад — и в проекте, где демо должно убедить незнакомого человека за две минуты, он был не второстепенным.
Что я взяла из аналогов
Пользовательских данных у проекта не было, поэтому единственным честным источником для меня стали существующие решения: как в других продуктах показывают глобус, спутники, траектории и большое количество объектов одновременно.
Почти все они оказались перегружены: на экране одновременно висят десятки аппаратов, орбиты пересекаются, служебная информация борется за внимание с картой. Для инструмента, которым пользуются каждый день, это оправданно. Для демо с двумя минутами и неподготовленным зрителем — провал: считывается «сложно», а не «мощно».
analog-dense-tracker.png
final-screen.png
2–3 скриншота аналогов с пометками, что именно в них перегружено, рядом — свой экран. Самый сильный before/after из доступных в проекте.
Что из этого следовало для дизайна:
Плотность — не достоинство. Я сознательно оставляла воздух там, где аналоги ставят данные.
Внимание должно быть направлено. В каждый момент на экране есть один главный объект — выбранный аппарат, его траектория, его зона.
Числа не убирать, но и не делать главными. Телеметрия живёт в карточке объекта: она доказывает, что за картинкой стоят настоящие расчёты, и не мешает первому взгляду.
Заглушка — нужны данные от автора. Какие именно продукты реально изучались: N2YO, KeepTrack, 3D Satellite Tracker, Satellite Tracker 3D, Orbit Codex Tracker — отметить те, что действительно смотрели, чтобы не приписать себе лишнего.
Ключевые решения
1. Тёмная тема и разреженный интерфейс — как ставка на восприятие
Тёмная тема формально следовала из стилистики Sofikom, но выбрала я её не только поэтому. На тёмном фоне светящаяся Земля, орбита и зона покрытия работают как источники света — глаз идёт к ним сам, без выделения рамками и подписями. Это ровно то, что нужно на стенде, где нет второго шанса объяснить, куда смотреть.
globe-screen.png
Чем заплатили. Тёмная тема жёстче к контрасту: тонкая линия орбиты и мелкие подписи в карточке объекта на ней теряются заметно быстрее, чем на светлой. Это компромисс, который остался в решении.
2. Движение как главный аргумент
Из всех возможностей системы самой убедительной я считала не функциональность, а движение: аппарат, идущий по орбите над реальной поверхностью Земли, за несколько секунд объясняет продукт лучше любого описания.
Поэтому визуальное представление траекторий я прорабатывала отдельно — как рисуется орбита, как читается положение аппарата относительно поверхности, что видно в момент, когда он уходит за горизонт. Именно на этот блок я закладывала больше всего графики — и именно здесь пришлось урезать сильнее всего.
3. Что происходит, когда объекты накладываются друг на друга
Интерфейс рассчитывался примерно на десяток аппаратов. Немного — но на сфере даже десяток даёт перекрытия: метки сходятся при повороте глобуса, проекции зон покрытия накладываются, орбиты пересекаются.
Это тот случай, когда демо ломается не на сложном сценарии, а на обычном. Человек поворачивает глобус, две метки слипаются — и вместо ощущения «система работает» появляется ощущение бага. Я проработала отдельные визуальные состояния для наложения: как ведут себя метки, попавшие друг на друга, и что происходит с пересекающимися проекциями зон.
Плюс к этому — состояния и ошибки по всем экранам. На демо-продукте это не формальность: любое пустое или сломанное состояние на стенде видит человек, которого мы пытаемся убедить.
marker-overlap.png
Заглушка — нужны данные от автора. Приложить макеты состояний при наложении меток и пересечении зон — в текущей версии кейса их нет вообще.
4. Дизайн в границах одного фронтендера
Самое постоянное ограничение проекта было не по срокам, а по реализации. Фронтенд делал один человек, и трёхмерная визуализация была новой задачей и для неё тоже. Отдельно упирались в производительность: отрисовка орбит, зон и сложной графики.
Разработка шла последовательно — сначала глобус, потом карта. Требование сделать оба режима пришло от аналитика: демо должно было показать широту технологических возможностей компании, поэтому выбирать между ними никто не собирался.
Моя работа здесь заключалась в том, чтобы дизайн не обгонял реализацию. Я сокращала визуальные эффекты и часть графики, которую хотела сделать сложнее и выразительнее — не потому, что она не нужна, а потому что нереализованная графика к дате выставки стоит ровно ноль, а урезанная, но работающая — приносит результат. Приоритет при сокращении был один: сначала то, что важнее показать потенциальному заказчику, потом всё остальное.
Чем заплатили. Визуально продукт получился сдержаннее, чем задумывался изначально. Это осознанный размен срока и надёжности на выразительность, и на дедлайне под выставку я бы сделала его снова.
Заглушка — нужны данные от автора. Конкретный пример урезанной графики или фичи — какую именно сложность пришлось упростить и до чего. Если сохранились ранние эскизы с более сложной графикой, rejected concept рядом с финалом сработает сильнее любого текста.
Финальное решение
Демо собрано как связная демонстрация, а не как набор функций. Сценарии выстроены так, чтобы каждый следующий добавлял к предыдущему один смысловой шаг.
Положение и траектория. Аппарат на орбите, движение относительно поверхности Земли, карточка объекта с телеметрией. Отвечает на вопрос «где он сейчас».
Два режима: глобус и карта. Глобус даёт физическую достоверность и эффект, карта — возможность видеть всю группировку сразу. Отвечает на вопрос «как посмотреть удобнее».
Поиск объектов. Поиск по названию и идентификатору, состояния выбора и предпросмотра. Отвечает на вопрос «как найти нужный аппарат среди остальных».
Зоны покрытия и покрытие в точке. Зона на глобусе и карте плюс сценарий «что видно из конкретной точки Земли». Отвечает на вопрос «а меня отсюда видно» — самый понятный вопрос для человека вне отрасли.
Запретные и специальные зоны. При пересечении зоны покрытия с ограниченной областью состояние аппарата меняется прямо на карте — инженерный расчёт превращается в один визуальный факт. Вместо того чтобы сопоставлять два источника данных, человек просто видит, что что-то изменилось.
Работа со временем. Просмотр состояния системы на выбранную дату и время — группировка перестаёт быть снимком и становится процессом.
search-objects.png
timeline.png
Сетка из экранов по одному на сценарий, включая поиск и таймлайн — оба есть в макетах, но пока нигде не показаны. Подписи короткие: экран должен говорить сам.
Результат
Что было сделано. Демо реализовано в коде и работало на стенде международной выставки. Проект прошёл полный путь от требований до работающего продукта за четыре месяца силами команды из четырёх человек.
Что осталось после. На основе демо аналитик собрал презентационное видео с демонстрацией экранов — компания использует его в дальнейших презентациях продукта. То есть интерфейс пережил само событие и стал материалом, которым продают.
Чего я не знаю. Сколько человек посмотрело демо, какие были вопросы и к чему это привело коммерчески. Я не участвовала в переговорах на стенде и не имела доступа к результатам продаж. Метрик по этому проекту у меня нет, и придумывать их я не буду.
Заглушка — нужны данные от автора. Точное название и год выставки (кандидат: «Российская неделя высоких технологий», 22–25 апреля, экспозиция «Навитех»); ссылка на презентационное видео или разрешение его показать; можно ли публично называть Sofikom — если нет, формулировка меняется на «внутренний стартап телеком-компании».
Что я поняла
Ограничение реализации — это часть дизайна, а не помеха ему. До этого проекта я относилась к «фронтенд не успеет» как к внешней проблеме. Здесь стало понятно, что решение, которое не будет сделано к дате, — это не решение. Сокращать собственную графику ради того, чтобы продукт работал на стенде, оказалось нормальной дизайнерской работой, а не поражением.
Опора на существующую дизайн-систему стоила выразительности. Мы строили интерфейс на дизайн-системе Sofikom, и в рамках срока это было правильно. Но она не была рассчитана на такой тип контента и, на мой взгляд, отставала от современных визуальных подходов. Сегодня я бы либо заложила время на её расширение под геоданные, либо аргументированно вынесла этот продукт за её пределы.
Проект вывел меня из привычного контекста. Я работала в основном с медийными продуктами, и здесь пришлось разбираться в предметной области, где интуиция не работает: орбиты, зоны покрытия, ограничения. Это изменило мой подход к незнакомым доменам — раньше я начинала с интерфейса, теперь начинаю с вопроса «что здесь вообще происходит физически».
Чего проекту не хватило. Мы ни разу не проверили демо на человеке со стороны. Проверка понятности на 3–5 людях вне отрасли стоила бы полдня и дала бы ответ на главный вопрос проекта — считывается ли продукт без объяснений. Сейчас я бы это сделала обязательно.
