Набор, который собирают при хирурге

Alcon делает офтальмологическое оборудование и расходники. Custom Pak (внутри — CPAK, дальше «пак») — это лоток, собранный под конкретную процедуру, конкретную клинику и конкретного хирурга: канюли нужного калибра, ножи, вискоэластик, салфетки, простыни, все в том количестве и той раскладке, как принято в этой операционной.

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

Кто в кадре

• Account Manager — торговый представитель, ездит по клиникам, сидит напротив хирурга и главврача
• CPAK / SAS Admin — внутренняя роль: цены, контракты, разбор расхождений, подготовка квот
• Regional Manager — смотрит на регион целиком, а не на отдельный пак
• Хирург и операционная сестра — не пользователи приложения, но именно они говорят, что в лотке не так

Моя зона — продуктовый дизайн: исследование вместе с командой, архитектура системы, ваерфреймы, визуал, макеты MVP и дизайн-система. Плюс 3D-модели позиций каталога — их я делал сам: без них proof of concept было нечем наполнить.

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

Софт у Alcon был, но десктопный — и на встречу он не ехал. Это и есть корень задачи: инструмент существовал там, где нет хирурга, а решение принималось там, где нет инструмента. Конкуренты в это время свои цифровые продукты уже двигали, так что вопрос стоял не «удобно ли», а насколько Alcon отстает.

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

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

Цикл ревизии

1. Клиент просит правку: добавить позицию, убрать, заменить неактивный артикул
2. Представитель считает цену и маржу, согласовывает изменения
3. Квота превращается в официальный контракт и уходит в производство
4. Поставка, склад, follow-up — и на любом шаге новая модификация

Каждый шаг — переписка. Между представителем, админом по ценам, регионом и производством. Пак существовал не как объект в системе, а как история сообщений о нем.

В Азии к этому добавляются перевод названий инструментов и часовые пояса: пока согласование доедет до США и вернется, проходят сутки. Путь японского представителя отличается от американского не объемом работы, а ожиданием — и это разные проблемы, которые нельзя лечить одним решением.

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

17

удаленных интервью: США, Канада, Европа, Австралия

2

очных интервью в Филадельфии

4

групповые сессии на выезде в Хьюстоне

Двадцать три сессии, и формат у них разный не случайно. План прямо ограничивал: Европа — только удаленно, поездки допускались по США. Отсюда перекос — живьем удалось посмотреть только американскую часть, остальное шло по видео, без возможности увидеть, что у человека реально лежит на столе.

Групповые сессии на выезде не заменяют интервью, но дают то, чего по видео не видно: как представители спорят о процессе между собой. Расхождение в том, «как у нас принято», — это и есть места, где продукт не может навязать один сценарий.

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

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

Из интервью собрали две персоны — те роли, вокруг которых строится продукт. Account Manager: цели по продажам, консультации по прибыльности практики, техподдержка. CPAK Admin: аудит, контракты, цены, разбор расхождений, отчеты по статусу.

Самое полезное в персоне оказалось не описание целей, а распределение устройств: телефон — 70% работы, планшет — 20%, ноутбук — 10%. Но планшет — это ровно та часть работы, которая происходит лицом к клиенту: презентация и разбор с хирургом. Отсюда и iPad, а не «еще один десктоп»: продукт живет в том устройстве, которое кладут на стол между собой и клиентом.

Дальше — journey map процесса ревизии, по фазам: запрос правок, внесение изменений и пересчет цены, превращение квоты в контракт и передача в производство, поставка с подфазами по складу и модификациям. Карту рисовали для представителя из США и из Японии на одной сетке, чтобы разница была видна не на словах.

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

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

Из чего состоит модель

• Дашборд адаптируется под роль: представитель, админ системы, админ страны, CPAK-админ, региональный менеджер
• Контекст страны и территории: страна выбирается одна, территорий — сколько нужно
• Каталог свой у каждого завода: одна и та же позиция не обязательно доступна везде
• Аккаунт клиента, внутри — паки, квоты, контракты и прототипы

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

	Что это значит на встрече
Create from scratch	Собрать с нуля — редкий случай, новая клиника
From BOM template	Взять шаблон под тип процедуры
Based on existing BOM	Взять прошлый пак этого хирурга и поправить
Sister pak	Тот же набор для второй операционной или второго врача
Create revision	Новая версия, старая остается в истории
Route pak / take ownership	Передать на согласование и явно взять ответственность
Make prototype	Показать вариант, не создавая обязательств

Route pak и take ownership — не украшение. Это замена переписке: раньше «кто сейчас держит этот пак» выяснялось в почте, теперь это состояние объекта, которое видно с дашборда.

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

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

Главное решение этого слоя: пак — не набор экранов, а один объект в пяти разрезах, переключаемых вкладками. Состав не теряется при переключении, и разговор с хирургом не превращается в навигацию.

	На какой вопрос отвечает
Bill of Materials	Что внутри и в каком количестве
Location View	Как это физически лежит в лотках
Pricing Analysis	Сколько стоит, какая маржа, нужно ли согласование
Comparison View	Чем отличается от другого пака или от прошлой версии
Revision View	Что менялось и кто менял

Comparison и Revision в бумажном процессе не существовали вообще: сравнить две версии пака можно было только двумя распечатками рядом. Поэтому эти вкладки закладывались с самого начала, а не «когда будет время».

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

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

Действия висят на самой позиции: посмотреть, заменить, открыть в каталоге, оставить заметку, перенести в другой лоток, удалить. Заменить — самое частое: хирург говорит «не эта канюля, а на 25G», и замена не должна выкидывать из пака в каталог и обратно.

Каталог открывается модальным окном поверх пака, а не отдельным разделом. Уйти в каталог и потерять контекст собранного пака — тот самый разрыв, из-за которого встреча превращалась в работу с бумагой.

Location View — единственная вкладка, которая отвечает на физический вопрос: пак реально собирается? Лоток имеет объем, инструменты лежат слоями, простыни идут сверху. В таблице это не видно, а на производстве и в операционной — видно сразу.

Чтобы проверить и саму идею, и отношение к ней, собрали proof of concept веб-версией: ключевая функциональность, реальная 3D-сцена, разложенные слои, тени. Веб — потому что PoC нужно было открыть на любом устройстве, и у пользователей на сессии, и у заказчика на защите.

3D-модели позиций каталога для этого PoC сделал сам. Это оказалось важнее, чем звучит: пока моделей нет, «3D-визуализация пака» — слайд, а не проверяемая гипотеза. С реальными моделями стало видно, какие позиции вообще опознаются в объеме, а какие превращаются в неразличимый белый брусок.

Параллельно сверялись с разработкой на техническую реализуемость: 3D в вебе и 3D на iPad — разные бюджеты, и обещать в макетах то, что не поедет на планшете, нельзя.

• Лоток разбирается на слои — видно, что под простыней
• Сцена вращается зажатым курсором, есть отмена и возврат
• Группы состава — Structure, Prep Tray, Main Pak — совпадают с реальными лотками
• Рядом всегда цена пака и число компонентов: 3D не отменяет цифр

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

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

	На какой вопрос отвечает
Немодерируемые тесты: first-click и прототип	Понятен ли концепт без объяснений — куда человек жмет первым
Интервью на PoC с задачами	Доходит ли человек до результата и что он думает про 3D

Отдельно сверили 3D-представление Bill of Materials с видением заказчика — там были свои ожидания, и расходиться с ними на защите дороже, чем на макете. Выводов вышло восемь, и главный оказался не тем, которого ждали.

1. Крупные качественные фотографии позиций ценнее 3D — и для представителей, и для сервисных специалистов
2. Региональные менеджеры не хотят, чтобы представитель занимался раскладкой по лоткам: это не его работа
3. Из двух стилей рендера все выбирают реалистичный, а не «контурный»
4. 3D полезнее всего новым хирургам и в обучении, а не на продаже
5. Дашборд ждут под роль и с действиями: что ждет согласования, что в работе, что в производстве
6. Иконку уведомлений читают как «что мне нужно сделать», а не как ленту событий
7. Шаблонами документов нужно управлять руками — удалять, импортировать, экспортировать
8. Цены и прайс-гайдлайны нужно импортировать, с превью до применения

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

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

После теста собрал рабочие экраны под MVP. Правки шли ровно по выводам: дашборд и списки — вокруг действий и статусов, каталог — вокруг фотографий и параметров, пак — вокруг цены и согласования.

Аккаунты

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

Каталог

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

Bill of Materials и цена

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

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

Location View

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

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

• Палитра и типографика — из системы компании, без своих кеглей и цветов
• Кнопки, поля, табы, теги, инлайн-сообщения, пагинация — дополненные состояния под новые сценарии
• Отдельная типографическая шкала под японский: Noto Sans JP

Японская шкала — не «на будущее». Это прямое следствие journey map: если в Азии часть работы уходит на перевод названий инструментов, интерфейс обязан нормально выглядеть на японском с первого дня, а не после локализации.

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

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

• Исследование: план, 23 сессии, две персоны, journey map по США и Японии
• Архитектура: диаграмма системы с ролями и потоками, вайрфреймы сценариев
• Концепт, проверенный на пользователях, и выводы теста
• Proof of concept 3D-раскладки в вебе
• Макеты MVP: аккаунты, каталог, BOM с прайсингом, Location View
• Дизайн-система: дополненные компоненты, палитра, типографика, иконки
• 3D-модели позиций каталога под PoC
• Прототипы — под показ заказчику и под тестирование

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

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

1. Ломался не первый сбор пака, а ревизии. Поэтому продукт спроектирован вокруг объекта с владельцем, статусом и историей, а не вокруг конструктора.
2. Пять вкладок одного пака вместо пяти экранов: состав, раскладка, цена, сравнение, история. Разговор с хирургом не должен превращаться в навигацию.
3. Тест перевернул приоритет: крупные фотографии позиций оказались нужнее 3D. Самая дорогая функция стала вспомогательным видом, а обещанием — каталог и понятная цена. Но узнать это можно было только собрав 3D по-настоящему: модели позиций я сделал сам, иначе гипотеза так и осталась бы слайдом.
4. Часовые пояса и перевод названий — это дизайн-требования, а не «особенности региона». Из них выросли статус пака, явная передача владения и японская типографика в системе.