Всем привет! Хочу поделиться своим опытом одной экспериментальной разработки, за которой стоит большая, на мой взгляд, идея: персонализированный интерфейс, который конфигурируется на основе потребностей клиента. Представьте, что два человека смотрят в одну и ту же программу, имеют одинаковые права доступа, но видят разные функции на экране своего монитора.
В этой статье расскажу о подготовительной части: о трудностях и преимуществах, которые пришлось взвесить, прежде чем вписаться в этот блудняк эту историю.
О проблеме
Я продакт-менеджер в компании Wrike и занимаюсь мобильной разработкой. Именно мобильная специфика впервые заставила меня посмотреть на продукт по-новому. Сервис у нас довольно большой, а клиенты порядочно требовательные и хотят иметь доступ к сервису, находясь вдали от рабочего места. Наша компания активно растёт, а значит и мобильное приложение пополняется новыми функциями. Но формат мобильного телефона не предполагает наличия сложных интерфейсов и разнообразия контролов. Откровенно говоря, было бы неплохо, чтобы любой сервис был как можно проще и понятнее вне зависимости от устройства, на котором к нему обращаются. Обычно у пользователя ограниченный набор действий, а остальной парк функций им не к чему. Вот только ввиду специфики нашего продукта этот набор действий у всех очень разный (что это за наборы расскажу во второй части статьи). Потому встал вопрос, как сделать универсальное приложение для всех и каждого.
Размышления на тему
Всё мне известное в этом мире развивается по вполне определённым правилам. Если что-то способно к выживанию, будь то идея или живой организм, оно неизбежно набирает массу. С ростом массы объекта растёт и занимаемое им пространство. Это новое пространство имеет свои контексты, которые влияют на объект, а значит, чтобы выжить, он (объект) должен адаптироваться. Приведу аналогию с начинающей IT-компанией. Сначала в ней два человека делают всё, каким-то образом разделяя обязанности. Оборот компании увеличивается, а вместе с ним возникают новые задачи, которые, например, связаны с безопасностью, аналитикой, законодательством разных стран и т.д. Зона ответственности компании растёт. И чтобы хорошо справляться с ней, нужно нанимать новых людей. И так, спустя время, в компании появляется большое количество отделов, которые специализируются на одной конкретной области или проблеме.
Эти правила отлично ложатся и на наш продукт: Wrike начинался с простого task management сервиса и вырос до системы управления работой на десятки тысяч человек. Нужно понимать, что у каждой компании свои процессы, софт, традиции и правила, которым новое ПО должно соответствовать. Чтобы пользователям было хорошо, нам пришлось очень многое сделать. Для пользователя это «очень многое» выражается в количестве функций и конфигураций рабочего процесса. Наряду с такой гибкостью мы не могли не заметить, как наши интерфейсы становились сложнее. Мы понимали, что разнообразие затрудняет выбор, увеличивает вероятность ошибки и время до выполнения конкретного действия. Продукт кажется пользователям сложным, а это всегда отрицательно влияет на конверсию.
Идея
Представьте мир продукт, в котором интерфейс содержит только те фичи, которые нужны конкретному пользователю. Нет лишней информации, нет онбординга в ненужные фичи (ненужность определяется потребностями пользователя), нет вообще ничего бесполезного, лишь эссенция того, что имеет смысл и нужно для работы именно вам. На это я и замахнулся — персонализированные интерфейсы для каждого пользователя. Первая мысль, которая мне пришла в голову, — это же очевидно, весь мир стремится к унификации и персонализации одновременно. Иначе говоря, всё более простые интерфейсы для пользователя и всё более сложные закулисные механизмы. Но коль это так очевидно, чего же никто еще не сделал? А не сделали, потому что это ой-как не просто.
Хорошенько пораскинув мозгами, я составил список трудностей, с которыми может столкнуться мечтатель на пути в утопию. Итак, поехали!
Какие задачи предстоит решить
Роль пользователя в компании
От разных пользователей надо прятать разные кнопки, ведь менеджерам нужно планирование, стейкхолдерам — отчёты, конечным пользователям — задачи для выполнения, а ребятам в полях — Requests (простите, но боюсь, что никто меня не поймет, если напишу «Запросы»). Продукт должен знать, какую функцию выполняет человек в компании. Понять это можно с помощью опроса пользователей внутри продукта, но кто ж их заполняет… И да, требовать мы этого не можем: люди заплатили за сервис, а не за прохождение нужных нам опросов. Так что функцию человека придётся воссоздавать через все доступные открытые источники: соцсети, блоги, базы на дисках из пригородных электричек. Наш продукт — платформа для управления проектами, потому роли такие, однако вы можете попробовать адаптировать этот пример к вашей специфике.
Дизайн
Допустим, мы знаем должность человека и на основе этого можем предположить, как он работает с системой. Теперь надо решить ряд UX-вопросов: «Как и куда мы спрячем ненужную пользователю функцию?» или «Как пользователь найдёт нужную функцию, если она спрятана?». Важно понимать, что гибкость интерфейсов должна быть запредельной, а принципы и правила их разработки — железными. Определение этих принципов может потребовать пересмотра всей системы дизайна.
Разработка
Когда вопросы от дизайнеров заканчиваются, задача превращается в четырёхмерный кубик Рубика. После в игру подключается разработка. Обычно, если продукт большой, то и команда разработки немаленькая. Чтобы применить правила, которые сформулировали дизайнеры, все разработчики должны использовать общие для всей платформы UI-компоненты (UI Kit), а не создавать новые интерфейсы при каждом возможном случае. Использовать такую систему, может, и не так сложно, однако для начала хорошо бы её иметь.
Знакомство с продуктом (Trial)
Даже если собрать все элементы интерфейса в логические группы, возникает следующий вопрос: «Какие из всех возможных конфигураций продукта показывать пользователям триала?». У нас ведь нет исторических данных об их работе, нам неведомы их процессы, а наши средние показатели по индустрии (релевантной, как нам кажется, для этого человека) больше похожи на клубок use-case’ов.
Обмен знаниями
Если говорить об уже существующих пользователях, то давайте рассмотрим такой случай: бывает, что клиенты делятся опытом, и это выражается в таких диалогах: «Я вчера нашёл такую кнопку, прям в один клик всё сделала!», а другой ему отвечает: «А покажи где!». Выходит, что у одного пользователя эта кнопка есть, а у другого на том же месте пустота. Баг? Фича? Настройки доступа? Полнолуние?
Legacy
Отдельного внимания требуют достаточно зрелые проекты, ведь там во многих местах чёрт ногу сломит. Прежде чем такую гибкость и красоту интерфейсов показать пользователю, надо порядочно порефакторить код.
Да, неясного очень много. Но давайте обратимся к тому, что мы можем получить, если попробуем реализовать подобный подход.
Что выиграет продукт и бизнес
Разработка
Как разработчик в прошлом не могу не упомянуть о плюсах с точки зрения кода. Как только инженерам говорят, что теперь есть флаг, который определяет видимость конкретного элемента, и на него нужно реагировать, то код сразу становится менее связанный, появляется больше абстракций, скорость разработки увеличивается, количество довольных разработчиков растёт. Это не мои фантазии, а пережитый этап. При должном внимании к подходу вы действительно можете оптимизировать свою разработку.
Данные
Систематизировав знания о ваших пользователях, вы можете определять паттерны использования продукта в зависимости от размера и типа аудитории, страны, вкусовых предпочтений, времени суток, да и вообще всего. Спустя время вы проведёте ручной анализ, накопите достаточно данных и поделитесь ими с ML. Есть хорошая вероятность получить интересные закономерности. Например, схожие по процессам клиенты могут не быть знакомы с какой-то функциональностью. Это станет толчком к тому, чтобы их с ней познакомить. Или окажется, что клиенты из разных индустрий имеют схожие процессы и т.д. Однако тут есть ограничение: если в продукте существует огромная вариативность действий, то, начиная с определённого размера компании или аккаунта, закономерности найти сложнее. Поэтому стоит создавать атомарные рабочие пространства по функциям людей в них, чтобы хоть как-то масштабироваться на крупных клиентов более-менее эффективно.
Пара примеров:
- scrum-команда, рабочие задачи/проекты/картинки/документы которой хранятся в одном месте в системе;
- департамент разработки, организованный по такому же принципу.
Дизайн
Интерфейсы в продукте также станут более продуманными. Появится чёткое разделение функционала и его группировка. Всё движение продукта будет направлено на унификацию и систематизацию интерфейсов и пользовательского опыта.
Продукт
Как я уже говорил, существует огромное количество use-case’ов, и то, что подходит одним, не вариант для других. Такая потребность в гибкости процессов появляется, когда продукт разворачивается внутри реальных условий компании и когда процессы должны быть выстроены с большим количеством вводных ограничений. Если вы знаете индустрию, то можете делать предположения, какие функции могут понадобиться пользователям определённого типа. Эти знания можно использовать при онбординге в продукт, чтобы как можно быстрее донести ценность до пользователя и повлиять на его конверсию.
Пользовательский опыт
Если посмотреть на специфичное программное обеспечение (например, для завода), будет явное разделение на операторов, которые управляют потоком данных через сложные интерфейсы, и исполнителей, которые работают лишь с конечными задачами, оформленными в минималистичную оболочку интерфейса. В таких продуктах широкого профиля, как Wrike, разбить интерфейс на конкретные функции сложно. Но всё же можно попытаться найти общие закономерности работы и попробовать представить их виде облегчённого интерфейса. Простота работы с такой системой оставит приятные впечатления у пользователя и повлияет на его возврат в продукт. Во второй части статьи я покажу, как это может выгодно сыграть для вас.
Бизнес
Любая растущая сущность в этом мире неизбежно делится, чтобы не набирать критическую массу, которая замедлит её движение. Достаточно вспомнить продукты Atlassian или Sales Force десять лет назад.
Это случается, на мой взгляд, по следующим причинам:
- Продукт становится популярным и появляется на рынках смежных отраслей. Чтобы остаться на этих рынках, продукт должен хорошо удовлетворять потребности клиентов. Следовательно, нужно разработать новый функционал. При этом часть существующего функционала оказывается бесполезной. Принимается решение сделать отдельный продукт, в котором лишних возможностей не будет.
- Текущие отрасли не стоят на месте — так электронные письма, чаты, документооборот и системы учёта столкнулись вместе и образовали индустрию совместного управления работой (хотя это было не в точности так, но аналогию, я надеюсь, вы поняли). В итоге, существующий рынок трансформировался или вовсе поделился на два, и продукт оказался уже на нескольких рынках. Вместе с этим и выросли потребности клиентов.
Если говорить с технической точки зрения, то значительная часть серверной логики может быть использована несколько раз. Например, уже существуют системы доставки уведомлений, авторизация, шифрование, и т.д. И всё это может работать на нас. Со стороны разработки же требуется только верная конфигурация и некоторое расширение функциональных возможностей.
Теперь давайте представим ситуацию, что мы выходим на новый рынок: много новой разработки, MVP, инвесторы гонят вперёд и всё в таком духе. Кодовая база растёт, как грибы после дождя, и спустя несколько таких экспансий поддерживать её становится очень трудно. Принимается решение разделить продукт на два, три и более. Наверное, такое решение поднимет волосы на голове у каждого человека в компании. В этой статье я не буду затрагивать маркетинг, правовые аспекты и т.п. и пока буду говорить о продуктовой и инжиниринговой части. Стоимость разделения кодовой базы будет колоссальная. Тысячи человеко-часов рефакторинга, тестирования и миллионы долларов. И это только инжиниринг. Редизайн компонентов потребуется и с UX-стороны. Но вас ждёт приятное удивление: разделение окажется не таким уж и болезненным, если вы с самого начала писали слабо связанный код и UI. И именно такой и будет кодовая база и внешний вид при разработке динамических интерфейсов. Я знаю, что это звучит несколько утопично, но подумайте об этом немного, поговорите с вашими разработчиками. Уверяю вас, смысл в этом есть. Более того, такая гибкость позволит вам быстрее выходить на новые рынки и создавать вертикальные решения, точечно закрывающие нужды пользователей.
Итог
Получилась хорошая сбалансированная концепция, в которой хватает как плюсов, так и минусов. Хорошая потому, что не цена разработки, а ваша стратегия определяет, стоит её реализовывать или нет. Но эта статья больше про размышления: этакий набор вводных для тех, кто решиться попробовать реализовать такую концепцию. Подойти к разработке этой идеи можно с совершенно разных сторон и конечные результаты очень вариативны. Во второй части статьи я расскажу, как мы начали этот путь и в какой его точке находимся сейчас. Ждите новую статью через недельку-другую.
Автор: Евгений Рубилов
