Юрий Юшкевич

Директор по информационным технологиям в AB Digital. Помогаю оптимизировать процесс разработки цифровых продуктов. Развиваю ключевые элементы внутренней платформы разработки. Отвечаю за направление IT4IT.

Lean UX в SAFe®

Дата: 16.12.2024

Lean UX (Lean User Experience или бережливый подход к проектированию пользовательского интерфейса) в SAFe® (Scaled Agile Framework®) — это командный подход к созданию более качественных продуктов, при котором меньше внимания уделяется теоретически идеальному дизайну, а больше — итеративному обучению, общему пользовательскому опыту и результатам для клиентов.

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

Как правило, UX отражает восприятие пользователем системы — простоту использования, полезность и эффективность пользовательского интерфейса (User Interface, UI). UX-дизайн направлен на создание систем, демонстрирующих глубокое понимание конечных пользователей. Он учитывает потребности и желания пользователей, принимая во внимание их контекст и ограничения.

При использовании методов Agile распространённой проблемой является то, как лучше всего включить UX-дизайн в цикл быстрой итерации, что приводит к законченной реализации новой функциональности. Когда команды пытаются решить сложные и, казалось бы, субъективные вопросы взаимодействия пользователей с системой, одновременно разрабатывая поэтапные улучшения, они часто перебирают множество вариантов дизайна, что приводит к разочарованию в Agile.

К счастью, движение Lean UX решает эту проблему с помощью Agile-разработки и подхода бережливого стартапа (Lean Startup). Мышление, принципы и практики SAFe отражают это мышление. Этот процесс часто начинается с цикла бережливого стартапа SAFe (Lean Startup Cycle), описанного в статье Эпик. Он продолжается разработкой фич и возможностей с помощью описанного здесь процесса Lean UX.

В результате Agile-команды и Agile Release Train (ART) могут использовать общую стратегию для быстрой разработки, быстрой обратной связи и целостного пользовательского опыта, который радует пользователей.

Процесс Lean UX

В книге «Lean UX» Готхельф и Сейден описывают модель, которую мы адаптировали для SAFe.

Гипотеза о выгоде

Подход Lean UX начинается с гипотезы о преимуществах: Agile-команды и UX-дизайнеры признают, что правильный ответ невозможно знать заранее. Вместо этого команды применяют Agile-методы, чтобы избежать предварительного масштабного проектирования (Big Design Up-Front, BDUF), и сосредотачиваются на создании гипотезы об ожидаемом бизнес-результате фичи. Затем они постепенно реализуют и тестируют эту гипотезу.

Матрицу фич и выгод в SAFe (Feature and Benefits, FAB) можно использовать для описания гипотезы по мере её продвижения через непрерывное исследование (Continuous Exploration, CE) в рамках конвейера непрерывной поставки (Continuous Delivery Pipeline, CDP):

Фича — короткая фраза, дающая название и контекст.
Гипотеза о выгоде — предлагаемая измеримая выгода конечного пользователя или бизнеса.

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

Результаты измеряются в аспекте «Релиз по требованию» (Release on Demand) в рамках CDP. Лучше всего это делать с помощью опережающих показателей для оценки того, насколько новая фича соответствует гипотезе о выгодах.

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

Совместное проектирование

Традиционно UX-дизайн был областью узкой специализации. Талантливые дизайнеры, умеющие взаимодействовать с пользователями и получившие специальное образование, полностью отвечали за процесс проектирования. Целью было создание предварительного дизайна, который идеален «вплоть до пикселя». Но эта работа часто выполнялась разрозненными специалистами, которые могли и не знать про систему и контекст ее использования. Успех оценивался тем, насколько хорошо реализованный пользовательский интерфейс соответствовал первоначальному UX-дизайну. В Lean UX-дизайне всё кардинально меняется:

В Lean UX нет места героям. Вся концепция дизайна как гипотезы сразу же отвергает представления о героизме; как дизайнер, вы должны ожидать, что многие из ваших идей потерпят неудачу при тестировании. Герои не признают неудач. Но дизайнеры Lean UX воспринимают их как часть процесса.

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

Agile-команды совместно отвечают за проектирование и реализацию пользовательского интерфейса, что значительно улучшает бизнес-результаты и сокращает время выхода на рынок. Кроме того, ещё одна важная цель — обеспечить единообразный пользовательский опыт на разных элементах системы или каналах (например, мобильных устройствах, веб-сайтах, киосках) или даже на разных продуктах одной компании. Чтобы обеспечить единообразие, необходимо найти баланс между децентрализованным контролем и централизацией определённых ресурсов для повторного использования (согласно принципу №9 — децентрализация принятия решений). Например, создание дизайна системы с набором стандартов, включающих все элементы пользовательского интерфейса, которые будут полезны ART и Value Streams, в том числе:

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

Эти централизованные ресурсы являются неотъемлемой частью архитектурной полосы (Architectural Runway), которая поддерживает децентрализованный контроль, признавая при этом, что некоторые элементы дизайна должны быть централизованными. В конце концов, эти решения принимаются нечасто, они долгосрочны и обеспечивают значительную экономию за счёт масштаба как для пользователей, так и для корпоративных приложений, как описано в принципе №9.

Создание MMF

С помощью гипотезы и дизайна команды могут реализовать функциональность в виде фичи, минимально пригодной для продажи (Minimum Marketable Feature, MMF). MMF — это минимальный набор функциональности, который должен быть предоставлен клиенту, чтобы он мог оценить ценность, а командам — чтобы проверить, верна ли гипотеза о выгоде.

Создавая MMF, ART-команды применяют принцип SAFe №4 — инкрементальные поставки с быстрыми циклами обучения, встроенными в процесс для реализации и оценки фич. Команды могут сохранять варианты с помощью вариативного проектирования (Set-Based Design), определяя первоначальный MMF.

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

Оценка

MMF оцениваются в процессе развертывания и выпуска (при необходимости). Существуют различные способы определить, обеспечивает ли фича надлежащие результаты. К ним относятся:

Наблюдение — по возможности наблюдайте непосредственно за использованием системы. Это возможность понять контекст и поведение пользователя.
Опросы пользователей — с помощью простой анкеты для конечных пользователей можно быстро получить обратную связь, когда прямое наблюдение невозможно.
Аналитика использования — команды, работающие по Lean-Agile, встраивают аналитику в свои приложения, что помогает подтвердить первоначальное использование и предоставляет телеметрию приложения, необходимую для поддержки модели непрерывной поставки. Телеметрия приложения обеспечивает постоянную обратную связь от пользователей и администраторов развернутой системы.
A/B-тестирование — это статистический способ оценки гипотезы, который опирается на то, что предпочтения пользователей невозможно предугадать заранее. Осознание этого освобождает, устраняя бесконечные споры между дизайнерами и разработчиками, которые, скорее всего, не будут пользоваться системой. Команды следуют принципу №3: предполагайте вариативность; сохраняйте возможности, чтобы как можно дольше сохранять варианты дизайна. И везде, где это целесообразно и экономически выгодно, они должны реализовывать несколько альтернатив для критически важных действий пользователей. Затем они могут протестировать эти другие варианты с помощью макетов, прототипов или даже полнофункциональных реализаций. В последнем случае разные версии могут быть доступны нескольким группам пользователей, возможно, в определённой последовательности и с учетом аналитики.

Короче говоря, измеримые результаты дают командам знания, необходимые для рефакторинга, корректировки, перепроектирования или даже отказа от фичи на основе исключительно объективных данных и отзывов пользователей. Измерение создаёт замкнутый процесс Lean UX, который итеративно ведёт к успешному результату на основе доказательств того, что фича соответствует гипотезе.

Внедрение Lean UX в SAFe®

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

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

Метки: SAFe Продукт

Автор:

Юрий Юшкевич

Поделиться

Product Owner и Product Manager в SAFe®

Тренинг SAFe® Product Owner/Product Manager раскрывает роли Владельца и Менеджера Продукта, работающих в крупной компании. По окончании тренинга и сдачи выходного экзамена участники получают международный сертификат Certified SAFe® Product Owner/Product Manager (POPM).

Зарегистрироваться