Я Алексей Красильников, UX-архитектор Центра продуктов Dozor в компании «РТК-Солар». Под моим крылом — продукты Solar Dozor, Solar webProxy, Solar addVisor. И я очень признателен своим талантливым коллегам по UX за то, что они следуют выбранному курсу, несмотря на все трудности. Эта статья — выжимка нашего командного опыта и пройденного пути. Она будет полезна тем, кто начинает решать задачи дизайна в работающих сервисах.
О дизайне принято думать в последнюю очередь. Это неправильно, но это факт. Так получается по разным причинам. В основном — когда скорость роста аудитории продукта и выход на рынок для компании оказываются важнее качества дизайна. Это особенно характерно для MVP (минимально жизнеспособный продукт) — сначала необходимо подтвердить, что ты решаешь правильную проблему для правильной аудитории на правильном рынке, а уже потом можно заниматься «шлифовкой». Затем все-таки наступает момент понимания важности дизайна, как одного компонента успеха продукта. Причины тоже могут быть разными — усиливаются конкуренты, идет негативная обратная связь от пользователей, неважная репутация бренда, происходит потеря аудитории, это просто «в тренде» и др.
И у нас — как у всех. Но вместо того, чтобы ориентироваться на абстрактные бизнес-задачи, пытаемся дотянуться до пользователей. Выясняем, кто они, какие у них ожидания и проблемы, какой выбирают сценарий для решения своей задачи. Далее на основе собранных данных формируем UX-видение, выстраиваем дальнейшую продуктовую UX-стратегию и планируем первую очередь задач. Но все это очень хорошо звучит только в теории и еще красочнее выглядит на слайдах демонстраций руководству.
В реальности мы встречаемся с такими проблемами:
До пользователей не дотянуться, а если и удается, то они шифруются.
Дизайн-система тормозит развитие продукта.
У UX-задач самый низкий приоритет.
Что значит «пользователи шифруются»
Суть проблемы:
Пользователи закрыты и категорически отказываются раскрывать свои сценарии работы — специфика сферы информационной безопасности. Попасть на площадки заказчиков занимает от двух недель до месяца и требует десяток согласований от вахтера до замдиректора.
Решение:
Бенчмаркинг — для нас это процесс определения, сбора и анализа лучших практик и примеров с целью развития собственного продукта. Мы проводим исследования среди конкурентных решений и информационных систем анализа данных и сопоставляем с нашим продуктом, определяем паттерны и строим гипотезы пользовательских сценариев.
Также у нас есть регулярные встречи, где мы демонстрируем результаты этих исследований для всей компании, приглашаем коллег поучаствовать в исследовании. Их знание, экспертиза и опыт работы с конкурентными решениями помогли нам в работе с гипотезами, сбором рекомендаций и приоритетов.
Эти подходы помогли понять, какие существуют паттерны поведения у разных пользователей и какие вообще бывают решения и интерфейсы. Можно что-то позаимствовать в свои сервисы и процессы или, наоборот, понять, как делать не нужно.
Дизайн-система тормозит развитие продукта
Суть проблемы:
Команда начинает воспринимать существующую дизайн-систему как руководство к действию и последнюю инстанцию: «У нас нет такого в библиотеке, мы не можем этого сделать». И здесь все упирается не только в нежелание разработки. Также звучат аргументы, что с добавлением новых компонентов увеличиваются время и бюджет разработки, непрозрачна целесообразность этого изменения, ведь ценность для пользователя с новым решением не очень однозначна.
Решение:
Если в дизайн-системе чего-то нет, это не значит, что оно там не может появиться. Слишком упираясь в системный подход, можно забыть про обычных людей, для которых и создается продукт. К дизайн-системе нужно относиться так же, как и к любому другому программному продукту, — составлять план развития и вносить изменения как на основе обратной связи, так и на основе собственных наблюдений. И что самое важное — полноценно закладывать время на доработки и изменения.
Дизайн-система не останавливает разработку, она постепенно растет в общем потоке работы и эволюционирует вместе с продуктом. Необходимо только соблюдать договоренности, распространять знания в команде и вовремя предупреждать об изменениях.
У UX-задач самый низкий приоритет
Суть проблемы:
UX-видение сформулировано, проработано текущее состояние продукта, распланированы шаги к реализации, но у задач от бизнеса более высокий приоритет. И если даже удалось вклиниться в производство, то, чем ближе релиз продукта, тем больше ваших задач оттуда выкидывается. Сроки, ресурсы, приоритеты…
Решение:
Во-первых, мы должны привязать UX-задачи к бизнес-приоритетам. Под последним мы понимаем качество продукта, сроки и риски выхода на рынок, увеличение аудитории. Второй шаг — четко сформулировать эти задачи и разбить их на реализуемые части. Это нужно, чтобы оценить трудозатраты и получить вменяемые цифры. Общие и большие задачи с формулировкой «сделать все красиво и удобно» — первые претенденты на вылет.
Следующий момент — мы немного изменили процесс, разработав инструмент для ускорения работы над фичами. В чем суть? Мы описали паттерны, различные стандарты вывода информации, типовые шаблоны для проектирования решений. С таким форматом уже смогла работать на ранних этапах проработки концепции вся команда. В обсуждении и согласовании решений фокус сместился на пользовательские сценарии, а не на конкретные визуальные решения. И вот тут проявилась ценность предлагаемых решений, уже существующих или новых:
повышение юзабилити и ускорение решения пользовательского сценария;
единообразие по системе и переиспользование интерфейсных решений в линейке продуктов;
более точные оценки по трудозатратам и, как следствие, попадание в планируемые сроки.
Объясню на пальцах. Раньше бизнес ставил задачи, аналитики их интерпретировали, описывали и ставили задачу UX-архитектору (то есть мне), тот на основе требований аналитиков формировал видение и передавал обратно. Аналитики шли к дизайнерам, которые трансформировали это видение в конкретные макеты. И уже с этим аналитики шли в команду, которая реализовывала все. Сейчас процесс выстроен так: получив задачу от бизнеса, аналитики сами формируют прототипы на основе типовых шаблонов, которые мы сделали, и визируют их у UX-архитектора. И после этого они сразу идут в команду, а не к дизайнерам. Когда задача не распыляется на множество людей, ее можно более точно оценить и распланировать. А если мы готовы сделать заявленное быстро, к нам больше доверия, что в итоге влияет на приоритетность дизайн-задач.
Примечательно, что, разработав дизайн-систему для себя, мы создали инструмент и для остальных. Он ускорил процесс работы над всеми фичами, не только UX: люди стали концентрироваться не на красоте картинки, а на сценарии, зачем это нужно.
Заключение
Конечно, это не все проблемы, которые встречаются на пути — в этом посте я обозначил лишь три. Работать в UX было бы, пожалуй, слишком легко, если бы их было всего три. Здесь я поделился нашим опытом поиска подхода к решению этих проблем. Что мы еще делаем? Помимо исследований и улучшения командных процессов, мы стремимся развивать культуру UX и клиентоориентированности в компании. Проводим лекции, встречи по генерации идей, делимся материалами и опытом и стараемся активно взаимодействовать со всеми подразделениями компании.
С правильной культурой достижения долгосрочны, а не «разваливаются», стоит только отвернуться. Партнером и дизайн-командой становится вся компания, а результатом дизайна — не только хорошие продукты, но и сама организация.
Делитесь в комментариях своими проблемами и подходами к их решению — будем вместе искать истину :)
Автор: Алексей Красильников, UX-архитектор Центра продуктов Dozor компании «РТК-Солар»
