Как спроектировать новую функцию, чтобы клиенты с удовольствием работали в личном кабинете?

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

Структура и внешний вид интерфейсов не появляются из воздуха. Их база — бизнес-требования. Клиент рассказывает о своих внутренних процессах, пожеланиях, ограничениях, профите от инструмента. А мы, IT-подрядчики, описание на бумаге и проговоренное голосом превращаем в прототип интерфейса.

О формировании требований и процессе прототипирования Павел Мелдажис, руководитель группы корпоративных решений, поговорил с Дмитрием Боханом, руководителем проекта развития личного кабинета ПГК, и Ольгой Завьяловой, ведущим аналитиком команды Ареал.

Павел Мелдажис: Для наглядности о сборе требований и прототипировании мы будем говорить на конкретном примере из конкретной системы. Поэтому сначала пара слов о проекте. Первая Грузовая Компания в сфере железнодорожных перевозок, наверное, известна всем. Ареал и ПГК сотрудничают с 2017 года. За пять лет серьезно обновили личный кабинет, разработали под него мобильное приложение и запустили Мобильный репортер.

Дмитрий Бохан: Системой ПГК Онлайн пользуются более тысячи крупных компаний: НЛМК, Северсталь, Евроцемент и другие. В личном кабинете огромное количество инструментов и функций. Клиент получает информацию о дислокации, она представлена в разных видах: в таблице, на карте с движением вагонов. Можно следить за выполнением своих заявок и финансовыми потоками. Для прогноза прибытия мы используем машинное обучение на основе истории, сезонности и других факторов.

Осмыслять сбор бизнес-требований и прототипирование мы будем на примере подачи заявки на перевозку.

Форма заявки — пять этапов с большим количеством показателей. Детальная информация по маршруту, грузу, объему и графику погрузок, грузополучателях и вагонах.

Павел Мелдажис: За пять лет в команде проекта появилось много экспертов, привлечены смежные консультанты. Но так было не всегда. Дима, расскажи, с чего все начиналось, с каких людей, как раскачивалась команда?

Дмитрий Бохан: У нас уже существовал личный кабинет, но он требовал обновления. Идея, что клиенты хотят получать более современные решения, похожие на привычные инструменты B2C сегмента, витала в воздухе.

Когда перезапуск кабинета только стартовал, у нас было несколько активистов, они и продвигали проект. Такие люди могут быть и со стороны бизнеса, и со стороны IT. Но IT-блок всегда зависим от бизнеса в крупных компаниях. Соответственно, нужно найти поддержку своей идеи, продукта, показать плюсы от реализации и сильную команду разработки.

Павел Мелдажис: Как на практике идея конкретного клиентского сервиса формируется? Вы закрываетесь в офисе и брейнстормите, или ты оформляешь идею, привлекаешь кого-то для прототипа?

Дмитрий Бохан: В случае с ПГК Онлайн, в частности с заявкой, руководство компании поставило перед нами задачу — активно продвигать и развивать кабинет. Мы получили сильную поддержку процесса. Затем мы вместе с вами, с Ареал, поэтапно:

• Мы собрали потребности от бизнеса. Ключевые контактные лица со стороны ПГК рассказали специалистам Ареал о процессе подачи и согласования заявки, потребностях клиентов и компании.
• Определили перечень функций. Ареал показали предварительное решение — какой интерфейс, функция закроют каждую задачу клиента и ПГК. Как правило это mind map, схема, письменное обоснование.
• Провели встречи с крупными компаниями и клиентами, которые делают небольшие отправки. Команда проекта проверила на «живых» пользователях кабинета удобство решения. Здесь появились первые наброски прототипа.
• Подготовили первичный прототип. Ареал на основе материалов всех встреч собрали первый вариант прототипа.
• Верхнеуровнево оценили проект. Это нужно для понимания сложности задачи и нашей готовности к затратам. На первый взгляд условная таблица может показаться простой в реализации. Но, если копнуть на уровень интеграций, то нужных полей не окажется в системе или они будут не подходящего формата для кабинета. Такие нюансы увеличивают время разработки и стоимость, их важно предусмотреть перед финальным согласованием.
• Защитили проект. Совместно презентовали проект руководству — прототип, смета, обоснование и перспективы.

Павел Мелдажис: Оля, расскажи, как это происходило с нашей стороны? Как мы формировали, прототип, как проходили встречи?

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

• Людям нравится оценивать наглядно, а не строить фантазии из объяснения на пальцах.
• Проще синхронизироваться в обсуждении, указав на кнопку в прототипе, чем объяснять относительно какого объекта она должна располагаться левее или правее. Время на подготовку прототипа компенсируется экономией на обсуждении.

Рождение прототипа происходит по следующему сценарию:

• Установочная встреча. Обозначаем конечную цель и краткую вводную, определяем подходы к задаче, этапы проекта и планируем следующие встречи. Все участники должны определить уровень своих знаний и понять, как их можно подтянуть. На встрече каждый примеряет на себя роль и «нужность» для команды, это влияет на мотивацию и вовлеченность.
• Брифинг и брейншторм. Разбираемся в тонкостях бизнес-процесса, генерим и обсуждаем решения на примере первичного прототипа. Таких встреч может быть несколько с разной степенью детализации и разным составом участников. Как правило, даже при полной инновации, хватает двух, трех встреч, чтобы подготовить прототип.
• Отрисовка прототипа, схем бизнес-процесса и других абстракций. Они помогают заказчику понять: тот ли это инструмент, который он хотел или решение не подходит и нужна полная переделка. В первом случае, работа приобретает конкретную направленность. Во втором, — исключаем одну из возможных концепций.

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

В случае с ПГК мы получили бумажную форму заявки и сразу начали прототипировать.

Вариантов интерфейса изначально было несколько, как практически во всех проектах. Они родились в бурной дискуссии с бизнес-экспертами, мы совместно искали варианты сокращения количества полей и упрощения клиентского пути. Например, для некоторых строк ввода появился автокомплит. В бумажной заявке клиент прописывал вручную и станцию отправления, и дорогу, и страну. При этом любая станция находится на определенной дороге, в определенной стране. Поэтому в личном кабинете достаточно указать станцию, а остальные данные подставляются автоматически на основе готовых справочников. Или для удобства восприятия рядом с таблицами появились автоматизированные графики.

Обсуждали каждое поле. Кто-то из клиентов ПГК, в силу специфики работы, активно использует одно, кто-то другое. В итоге нашли баланс и оставили оптимальный состав полей. Второстепенные постарались сделать менее заметными, чтобы они не перетягивали внимание. Например, в форме подачи заявки «Пункт отправления» и «Пункт назначения» появляются, если выбран чекбокс «Станция за пределами колеи 1 520». Подавляющее большинство перевозок проходит в пределах колеи 1 520, поэтому поля используются редко. Или «Станция перехода» нужна только если маршрут перевозки пересекает границу РФ, поэтому тоже используется редко.

Один вариант прототипа стал ведущим и пошел в реализацию. Но! Всегда нужно держать в голове, что процесс прототипирования живой, постоянно движущийся вперед. Пришли дизайнеры со своим видением — снова стали актуальными вопросы оптимизации интерфейса. Прошло время с внедрения заявки — опыт использования подсказал новые идеи и выявил дополнительные потребности в справочниках и данных. Или развитие внутренних информационных систем ПГК позволило автоматизировать более сложные процессы. Мы продолжаем искать пути для улучшения.

Павел Мелдажис: У прототипа есть вспомогательные средства?

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

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

Дмитрий Бохан: На любой встрече рождается миллион идей, даже в обсуждении и согласовании кусочка заполнения заявки. Мне, как модератору, требуется всю рабочую группу держать в одном векторе. Если не получается принять окончательное решение, то я «паркую» обсуждение до конца встречи. Возможно, со временем родится ответ, и дилемма будет решена просто. Второй путь — задать вопрос клиенту ПГК «Как вам удобнее заполнять заявку?». Кабинет в первую очередь для клиента, его опыт — оптимальное решение.

Павел Мелдажис: Действительно делаете замеры?

Дмитрий Бохан: Да-да. Много CustDEV-а. Спрашиваем, что хотят видеть пользователи, что изменить. Стараемся привлекать разных клиентов по масштабу, виду РПС, чтобы понять общую потребность, а не узкоспециализированную.

Павел Мелдажис: Я знаю, что вы сравнивали, насколько быстрее заполнять заявку в вебе, чем по старинке. Какие результаты? Дмитрий Бохан: Получилось в 3-4 раза быстрее через личный кабинет. Убирается обмен бумажными документами: сканировать, приложить, отправить. Менеджеру ПГК не нужно вбивать заявку в систему, она сразу туда попадает и идет в работу. Есть возможность полностью скопировать предыдущую заявку, изменив только период. Кроме скорости появляется прозрачность. Клиент видит весь объем поданных документов, статусы, согласованные заявки. Руководству доступна полная картина — сколько запросов по разным направлениям перевозки отправлено, сколько по факту поехало.

Для стратегических решений такая цифровизация в подаче заявки огромный плюс. Например, если менеджер с логистами понимают, что перевозка не оптимальна или не может быть выполнена, то сразу дают клиенту обоснование. В Личном кабинете она всегда доступна, можно посмотреть данные за интересующий промежуток времени.

Павел Мелдажис: Получается, что есть четыре стадии создания прототипа. Первая — переложить внутренний процесс в цифру, как есть. Вторая — обсудить с бизнесом прототип, упростить и найти оптимальный формат. Третья — аналитика, уточнить у пользователей насколько инструмент удобный.Четвертая — если нужно возобновить общую дискуссию об оптимизации в момент дизайна.

Когда в этом процессе появляются технические специалисты?

Дмитрий Бохан: Когда согласован верхнеуровневый прототип. Технари объясняют, возможно ли реализовать то, что мы спроектировали. Иногда желания расходятся с возможностями. Чем раньше мы поймем ограничивающие факторы, тем проще будет согласовать прототип. Но обычно сразу, как появляется идея, обсуждаются вопросы: есть ли в системе эти данные? В какую систему планируем сохранять? Если ответов нет, то идея дальше не развивается.

Ольга Завьялова: Я описываю эти предварительные технические требования: какую информацию кабинет будет принимать из систем ПГК, какую передавать, какие промежуточные статусы будет запрашивать. На этапе обсуждения задачи с бизнес-экспертами можно получить общие сведения о наличии данных, автоматизированных процессах, потенциальных сложностях. Уже после подготовительной работы мы выходим на обсуждение с техническими специалистами ПГК.

Павел Мелдажис: В какой момент пишется техническое задание?

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

Дмитрий Бохан: ПГК-Онлайн разрабатывают минимум две команды. Первая дорабатывает мастер-систему SAP. Вторая, Ареал, занимается макросервисами и поднятием мидпойнтов на стороне личного кабинета. Сложный момент — синхронизировать подрядчиков, избежать потери данных. Все должны быть в курсе доработок обеих систем. Поэтому техническое задание для личного кабинета согласуется с командой SAP. А техническое задание на доработку SAP согласуется с командой Ареал. Нет потерь в обмене знаний.

Павел Мелдажис: Если задача постоянно меняется, появляются новые вводные, корректируются интерфейсы, дизайн, — как подходить к оплате?

Дмитрий Бохан: Важно понять и принять, что личный кабинет — сложная разработка. Мы декомпозируем и разбиваем финансовые затраты на несколько частей. Первая — это основной инструментарий, и последующие — доработки, части поменьше. Соответственно есть бОльшая часть бюджета на главную разработку и несколько запасных частей для доработок в перспективе. В итоге в запланированный изначально бюджет мы укладываемся и получаем работающий инструмент. Так было и с заявкой. Первый шаг — дефолтная возможность подать заявку. Сейчас 70% заявок оформляются онлайн и начинают возникать дополнительные требования. Их реализация, а значит новый виток финансирования, — следующие шаги.

В оплате мы перешли на Time & Material, платим за время сотрудника. Раньше, с фиксированным бюджетом, было проще контролировать разработку и её стоимость. Понятный объем задач, понятный результат. Но эти плюсы перекрывает возможность в формате T&M быть гибкими, быстрее доносить новые функции до клиента, оперативно вносить изменения. Пока при Fix&Price уточняешь ТЗ (никто из сторон не готов фиксировать бюджет за непонятный объем работы), не говоря о длительных процессах согласования в больших компаниях, в формате T&M можно уже запустить первую версию.

Вопрос контроля решают двухнедельные спринты. В конце каждых двух недель подрядчик демонстрирует нам результат и предоставляет отчет по трудозатратам. Вопрос перерасхода решает прозрачность и дисциплина внутри команды разработчиков. Программисты и менеджер проводят ежедневные стендапы. Их главная цель — понять есть ли проблемы с текущими задачами, идем по графику или выбиваемся. Если реальные затраты оказались выше запланированных, мы об этом узнаем в середине спринта, а не на сдаче. Поэтому сможем оперативно поменять стратегию или план. Риски потратить существенно больше оценки или уйти от первоначальной задачи минимальны. Золотое правило Т&М — только после законченной реализации функции начинать новую. У заказчика есть большой соблазн накидать много задач и утонуть в незаконченных сервисах.

Павел Мелдажис: Если подводить итог беседе, то рабочий процесс превращения бизнес идеи в проект удобного интерфейса можно представить так.

На этапе идеи привлекаются активные сотрудники. Они проводят ряд встреч, общаются между собой и с представителями бизнеса на разных уровнях, активно задействуют подрядчика. Из этих евангелистов складывается команда, которая потом «ведет» весь проект. Прототип рождается из встреч и формирования бизнес-требований. Это должно произойти как можно раньше, чтобы участники команды могли предметно обсуждать и критиковать решение. Затем вступают технические специалисты, определяют возможность и сложность реализации прототипа. Дизайнеры вносят правки в продукт с точки зрения удобства для пользователя. Все это завершается контролем реализации со стороны Product Owner и непосредственных пользователей.

Повторим советы:

• Команда. Важна активность и желание участвовать в судьбе проекта.
• Прототип. Он должен появится как можно раньше, это помогает в коммуникации и решении спорных вопросов.
• Требования. Требования для прототипа должны идти от сотрудников компании на разных уровнях и с разными задачами. Так на руках будет целостное представление о бизнес-процессе и понимание, как его перенести в онлайн.
• Гибкость. Прототип — живой организм, он меняется со временем, приходом новых специалистов, появлением новых задач.
• Пользователи. Они главные эксперты в удобстве личного кабинета или его отсутствии. Пусть клиенты участвуют в принятии решений.
• Информация. Технические особенности нужно продумать во время разработки прототипа. Это поможет на этапе технической реализации не править интерфейсы из-за отсутствия информации во внутренней системе заказчика.
• Оплата. Т&М — отличный выбор для проекта, если готовы все стороны. Заказчик готов выделить время, контролировать, равномерно распределять задачи и своевременно принимать результат. Подрядчик готов предоставить ресурсы, оперативную коммуникацию, быструю оценку обновлений и включение в проект. Т&М даст более быстрый результат и гибкость в изменении сервиса.

В следующей статье мы расскажем о UX/UI дизайне личного кабинета транспортной компании.