Персонализированный интерфейс. Часть 1. Плюсы и минусы концепции



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

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

    О проблеме


    Я продакт-менеджер в компании 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. И именно такой и будет кодовая база и внешний вид при разработке динамических интерфейсов. Я знаю, что это звучит несколько утопично, но подумайте об этом немного, поговорите с вашими разработчиками. Уверяю вас, смысл в этом есть. Более того, такая гибкость позволит вам быстрее выходить на новые рынки и создавать вертикальные решения, точечно закрывающие нужды пользователей.

    Итог


    Получилась хорошая сбалансированная концепция, в которой хватает как плюсов, так и минусов. Хорошая потому, что не цена разработки, а ваша стратегия определяет, стоит её реализовывать или нет. Но эта статья больше про размышления: этакий набор вводных для тех, кто решиться попробовать реализовать такую концепцию. Подойти к разработке этой идеи можно с совершенно разных сторон и конечные результаты очень вариативны. Во второй части статьи я расскажу, как мы начали этот путь и в какой его точке находимся сейчас. Ждите новую статью через недельку-другую.
    Wrike
    Wrike делает совместную работу над проектами проще

    Комментарии 24

      +1

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

        0
        Согласен. Это вполне вписывается в эту концепцию. Так же добавлю, что как один из путей развития автоматической настройки интерфейсов можно подумать о accessibility. Скажем на входе в систему человек указывает свои возможности и интерфейс под них подстраивается. Но для меня эта история ещё только впереди)
        +4

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

          0

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

            0
            Ну уйдут, и? Сколько времени понадобиться саппорт инженеру, чтобы понять что пункт меню «Файл» теперь называется «Гравицапы > мои > локальные >» И как не застрелиться после этого )))
              0
              Ваше замечание валидное. Подобное тоже приходило мне в голову, но такое поведение кажется уж очень сложным, то есть спроектировать систему таким образом логически не просто.
              А вообще я думаю названия менять не стоит. За определённой функцией в системе спрятано определённое действие. Имя должно отображать суть этого действия. Если названия меняются, а функция остаётся прежней, то больше похоже на логическую ошибку.
                +1
                Тоже мне проблема.
                В опере престо видимые пользователю именования пунктов меню можно было переименовать как угодно — потому что на уровне движка броузер для менюшек оперировал уникальными системными идентификаторами.
                Соответственно саппорт накатывает свой профиль с соответствием идентификатор-именование и видит свои стандартные наименования.
              0
              Я думаю во времена консоли и перехода к графической оболочке так же были подобные мнения.
              Просто система в целом должна быть для этого подготовлена, это же пока размышления )
                0
                В точку! В первое время мы столкнулись с зачатками этой проблемы, но об этом во второй части) Эта же про теорию и возможности.
                Сразу скажу, что адекватный вариант решения тут один — зайти от лица пользователя (скажем access code какой-нибудь на один час). Но в любом случае при таком подходе требуется иметь очень грамотный штат тех. поддержки, которая будет в курсе работы принципов и механик настройки интерфейса
                  0
                  Я с этим сталкиваюсь постоянно причем в более менее стандартных конфигурациях 1С.
                  Тут даже грамотный штат тех поддержки может не помочь, т.к. вариантов формирования интерфейса теоретически может быть очень много, все зависит от фантазии разработчиков.
                +1
                Представьте, что два человека смотрят в одну и ту же программу, имеют одинаковые права доступа, но видят разные функции на экране своего монитора.


                «Не знаю, у меня все работает»
                  0
                  В этом стремлении к идеалу главное всегда помнить простую вещь — всем не угодишь никогда. Вот парни из одной редмондской компании очень хорошо это понимают.

                  Тут немного мерзкой действительности — когда у всех всё «одинаковое», и у одному неудобно, то это его проблема. А когда всё у всех разное, но один не смог найти свой идеал — это ваша проблема. А у вашей компании есть ресурсы решать такие проблемы?
                    0
                    Боюсь «мерзкая действительность» действительно существует.
                    Что же про ресурсы, то мы их на решение таких проблем не имеем. И да, сейчас мы придерживаемся схожего с вами мнения про удобство и не удобство одинаковых интерфейсов для разных пользователей.
                    Но это, кстати, решаемая проблема. Можно возложить настройку на пользователя. И это имеет сплошные плюсы. Все детали будут во второй статье.
                    +1

                    Рабочий стол на компе или телефоне — пример такого гибкого интерфейса. Когда разные кластеры пользователей используют разный функционал продукта — это самое лучшее решение.


                    У каждого на телефоне разный набор иконок, но ни у кого это не вызывает вопросов.

                      +1

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

                        0
                        Я понимаю ваши опасения, но как я писал выше, гибкость системы в руках её разработчиков. Если проектирование будет таким, что всё скачет перед глазами пользователя, то тут уж не вина концепции, а, как говорил мой преподавать, «кудрявые ручки».
                        Хочу отметить, что эта статья про размышления и без неё я не мог позволить себе говорить о практической части. Во второй части я расскажу что сделал, чтобы избежать подобных проблем с вайфаем.
                          0
                          Удачи вам, надеюсь у вас получится сделать такой интерфейс!
                          Однако у меня другое мнение, должны быть стандарты и приложения должны следовать этим стандартам (начиная с ОС), если давать волю разработчикам и пользователям, то они могут все слишком переделать.
                            0
                            Спасибо за проявленный интерес! Я был бы рад услышать ваше мнение о второй части, как она будет готова.
                        0
                        Отличное замечание! Примерно о подобном и пойдёт речь во второй части. Особенности мобильного телефона и рабочего стола в том, что пользователь сам настраивает себе окружение. Тут важно понимать, что система предлагает ему такую возможность.
                        0
                        Тут следует упомянуть управляемый интерфейс от 1с, где пользователь сам может настраивать (скрывать, перетсавлять, задавать условное оформление) элементы интерфейса.
                          0
                          Вы правы, в общем в этом направлении мы и пошли. Во второй части я расскажу о подходе и гипотезах, которые мы проверяли, а так же о том, что мерили как это отразилось на пользователях.
                          Можем копнуть глубже и вспомнить microsoft office, который еще в 98 версии позволял вынести нужные значки в быстрый доступ, а лишнее убрать
                          Я не претендую на уникальность разработки, скорее хочу подчеркнуть, что вижу ценность в том, чтобы софт был максимально полезен и не отвлекал людей от их основного рода деятельности. Люди любят свою работу, но случается, что процессы и софт вокруг приносят сплошное разочарование от процесса.
                          0
                          Вообще не вижу проблемы, многий софт (не мобильный) давно так умеет, но 99,9% пользователей этим не пользуются. Настройка меню (т.е. функционала) под себя (и/или в зависимости от роли) присутствует очень давно и очень много где.
                          Далее, даже если пользователь может переименовать (вместо — «Файл->Открыть» хочет — «Планетарные->Вжухнуть»), то пусть делает что хочет. Нажатие кнопки, ярлыка, картинки и т.д. не должно вызывать функцию напрямую, а должно генерировать событие с уникальным ID, которое обрабатывается основным потоком и уже выполняет функцию. И тогда можно пользователю хоть самому рисовать интерфейс. Хочешь это будет пункт меню, хочешь ярлычок, а можно и параллельно.
                          И, как уже говорил выше, все это давно есть и применяется. Но обычно в корпоративной среде, обычным пользователям это мало интересно.
                            0
                            >Настройка меню (т.е. функционала) под себя (и/или в зависимости от роли) присутствует очень давно и очень много где.

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

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

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

                            Самое читаемое