Привет, меня зовут Федоров Кирилл, я менеджер продукта компании Forecast NOW!. Мы делаем систему для прогнозирования спроса, автозаказа и управления запасами. В конце прошлого года мы выпустили новую версию с обновленным интерфейсом. В статье расскажу о том, почему решили менять интерфейс, как тестировали новые наработки и с какими сложностями столкнулись в процессе. 

Почему возникла необходимость менять интерфейс

На это было несколько причин. Первая — логика перехода между вкладок была не всегда понятна пользователям системы. Тут следует внести ясность. Главная рабочая панель программы состоит из вкладок с настройками.

Выше области вкладок есть панель инструментов. Когда пользователи переходили между вкладками, за пределами области вкладки менялась панель инструментов. Это было непривычно для них. Так получилось, потому что продукт постепенно обрастал новым функционалом. За годы разработки арсенал возможностей программы вырос в несколько раз. Все эти функции нужно было добавлять на рабочие вкладки программы, где часто не хватало места. В итоге логика размещения настроек не всегда совпадала с представлениями пользователей, и интерфейс был перенасыщенным. Особенно остро этот момент ощущался с новыми пользователями.

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

Третья причина: из-за обилия функций было неудобно работать на устройствах с небольшим экраном. Если пользователь открывал программу на 14–15 дюймовом ноутбуке, то большинство настроек не помещалось на экран, а их раскрытие занимало большую часть видимой области.

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

Как пользовательский опыт изменил наш подход

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

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

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

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

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

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

Логичнее казалось переместить вкладки вверх, сделать так, чтобы изменение самой главной панели инструментов происходило в зависимости от контекста, т. е. от выбранной вкладки. 

На этом этапе было подготовлено несколько различных макетов с проработанной логикой. 

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

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

Выбор решения по новому дизайну

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

Практически для всех один из основных рабочих инструментов — это MS Excel. Кроме того, второй по популярности программой, с которой работают наши пользователи, была Power BI от Microsoft, и она тоже имеет схожий интерфейс с Excel. 

Значит, интерфейс программы должен быть схож именно с Excel, чтобы пользователи могли максимально быстро адаптироваться. Я стал изучать этот вопрос подробнее. Оказалось, что дизайн Excel и Power BI разработан с применением дизайн-системы Fluent Design от Microsoft. У неё есть свои гайды по стилю, которые мы могли бы использовать для интерфейса нашей системы.

Стало понятно: это именно то, что нам нужно. 

Разработка нового интерфейса

Далее сделали несколько макетов с дизайном, схожим с программами из пакета MS Office, и показали их пользователям системы.

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

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

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

Однако при попытке реализации мы снова столкнулись с проблемой сложности переделки главной панели инструментов. Как я отмечал выше, она была написана с использованием библиотеки QtitanRibbon, и плотно интегрирована в архитектуру интерфейса программы. Но использовать её в новом интерфейсе уже было нельзя, потому что там был ряд ограничений, который не позволял реализовать изменения согласно гайдлайну Fluent Design. Поэтому фактически пришлось делать интерфейс заново: убирать код, необходимый для использования вышеупомянутой библиотеки и писать новый. Из-за этого процесс затянулся практически на год. 

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

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

Фидбек от пользователей

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

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

Диаграмма дизайн процесса

Подводя итоги, можно привести такую схему дизайн процесса по смене интерфейса