Agile UX: как включить UX и дизайн продукта в Agile

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

Но инженерия не работает в вакууме. Чертежи, идеи, проекты и концепции исходят от специалистов по дизайну продуктов, которые определяют макеты, потоки и интерактивность. Это люди и команды, не являющиеся инженерами, которые разделяют цели DevOps и желаемые результаты.

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

Разработчики и инженеры-архитекторы хотят участвовать в разработке программного обеспечения или системы, когда продуктовые и творческие группы разрабатывают программное обеспечение или систему. Но где это в нынешнем определении DevOps? Продуктовые, UX и творческие команды хотят оставаться вовлеченными в инженерные процессы, но многие методологии исключают их. Это старые бункеры, которые нам нужно разрушить.

Ваши клиенты видят только ваш пользовательский опыт (UX). Они не видят, сколько у вас разработчиков и какой вы Agile или Lean. Они понятия не имеют, какие инструменты DevOps используются. UX вашей компании — это продукт, и он может сделать вас лучше или сломать. Они задаются вопросом, кто построил этот кусок хлама. С такой большой конкуренцией и людьми, которые с радостью удалят приложение или покинут веб-сайт, получите ли вы второй шанс с клиентом, который вас бросил?

Agile редко тренируется на UX или работает со специалистами по UX

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

SAFe Agile совершает ошибку, решая, что лучший способ решить проблему разрозненности UX — полностью исключить их. SAFe «расширяет возможности Agile-команд» для создания собственного «бережливого UX». По мере того, как все больше компаний понимают ценность привлечения специалистов по UX и полного UX-процесса, SAFe движется в неправильном направлении.

Отсутствие объяснения UX и их процессов в Agile-тренингах и книгах привело к тому, что команды по всему миру исключили или свели к минимуму привлечение специалистов-дизайнеров продуктов.

• Когда вы ошибочно представляете, что UX просто рисует прямоугольники на страницах, легко предположить: «Я могу сделать эту работу». Подобно тому, как многие слушатели American Idol уверены, что они лучшие певцы на планете, большинство продакт-менеджеров и инженеров считают себя лучшими в UX. Обычно это означает, что они считают, что отлично разрабатывают экраны. Но поскольку в этой статье объясняется, что на самом деле входит в работу с UX, вы увидите, что специалист по UX не увидит в разработчике, который делает вайрфреймы, человека, которому следует давать задачи UX.
• Книги по Scrum предполагают, что если специалист по UX становится узким местом, ему следует обучать не-UX роли выполнять свою работу. Такое решение редко предлагается в отношении других ролей в разработке программного обеспечения; никто не захочет, чтобы неподготовленный или неопытный разработчик занимался кодированием, даже после буткемпа или прочтения книги по программированию. Мы никогда не советуем, если разработчик становится узким местом, он должен обучить менеджера проекта программированию.
• Менеджеры по найму, которые ошибочно полагают, что UX — это художественная (UI) работа, нанимают художников для выполнения UX-работы. Образовательная степень в области UX и UI не пересекается. Природные таланты часто не пересекаются; кто-то, кто хорош в UX, может быть плохим художником, и наоборот. Наем для «UX / UI» часто дает вам отличного художника с минимальным опытом UX, знаниями, процессами или образованием.

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

Важность привлечения опытных UX-специалистов в Agile

В конце 2018 года консалтинговая фирма McKinsey & Company опубликовала отчет «Ценность дизайна для бизнеса» об исследовании, которое они провели с более чем 300 компаниями.

Они обнаружили, что «Дизайн — это единственный способ, которым компании могут выделиться из толпы». Когда у конкурентов близкие наборы функций, что выделяет их? Иногда о дизайне думают просто как об эстетике или о том, что делает его похожим на наш бренд. Но при использовании с «UX» дизайн означает архитектуру функций и решений, принятых в отношении экранов, шагов, потоков, макетов, процессов, организации и меню.

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

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

McKinsey собрала количественные данные и обнаружила, что фирмы, использующие дизайн UX, получают на 32% больше доходов и на 56% больше доходов акционеров за 5-летний период. Заявления о том, что ваша компания ориентирована на пользователя, недостаточно. Вы должны пройти путь, интегрируя практиков UX и процессы от планирования и портфолио до разработки и контроля качества.

Процессы разработки программного обеспечения с UX и без него

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

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

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

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

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

Если кто-то меняет свое мнение в процессе, этот человек говорит с UX, а не отправляет это как запрос на изменение разработчикам. UX вмешивается во время их процесса, и ничего не отправляется в разработку, если UX не участвует в проектах, решениях и тестировании на реальных или архетипических клиентах.

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

UX имеет формализованный процесс

Ориентированное на пользователя проектирование (UCD) — это формализованный процесс, который включает в себя задачи, которые направляют специалистов по UX на исследование, проектирование, прототипирование, тестирование на реальных или архетипических пользователях, а затем итерацию на основе результатов тестирования.

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

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

Исследования — важная часть того, что делает UX. Это не ориентировано на пользователя без участия пользователей. Статистика и количественные данные — это прекрасно, но ничто не заменит опрос пользователей, их глубокое понимание и получение качественных данных. UX хочет знать почему, а не только что.

UX-исследование также объединяет товарищей по команде на одной волне, объединяя всех вокруг персон, архетипов целевых клиентов. Основываясь на интервью с пользователями, мы объединяем то, что узнали, и сводим всех к 6 или менее личностям. Что их мотивирует? Что им нужно делать? Где возможности для нашей компании, продукта или услуги?

Лучшее использование персон было бы включать их везде. Продукт представляет функции на основе персонажей (и хороших данных). UX-дизайн на основе персонажей. QA-тесты, представляя, что они и есть эти персонажи. Маркетинг может добавить свои демографические и другие данные, но они также должны учитывать, как голос бренда, социальные сети и реклама взаимодействуют с персонажами.

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

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

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

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

UX-прототипирование делается для того, чтобы:

• Мозговой штурм
• Сотрудничать
• Итерация
• Исследуйте решения
• Питч к инвесторам (для стартапов)
• Протестируйте прототип, чтобы убедиться, что решение хорошо взаимодействует с целевой аудиторией.
• Предоставьте интерактивную модель разработчикам или другим товарищам по команде, которая часто предпочтительнее страниц документации (и не интерактивная модель).

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

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

Есть 5 основных причин, по которым UX запускает тесты перед тем, как передать их инженерам:

1. Лучшее использование времени и ресурсов инженеров. Если вы хотите, чтобы участники тестирования увидели готовый продукт, созданный инженерами, вы должны собрать и протестировать его на наличие ошибок. Если UX-тестирование выявит необходимые изменения, разработчикам придется перестраиваться, а QA придется повторно тестировать. Если UX-тестирование показало большую неудачу концепции, это может означать, что время разработки было потрачено впустую, поскольку это не тот код, который где-нибудь окажется. Концепцию нужно было переосмыслить, переработать и заново протестировать.
2. Повторяйте за кулисами. Когда компании просто создают продукт, просто отправляют его, дорабатывают, снова создают и отправляют, это означает, что клиенты видят множество версий. Они видят, как идет работа, и наблюдают, как делают колбасу. Это часто вызывает разочарование и сбивает с толку клиентов, требуя от клиентов постоянного повторного изучения системы, которая развивается. Лучше выполнять итерацию за кулисами процесса UX и четко объяснять тестировщикам, что это прототип или демонстрационная версия.
3. Мониторинг и измерение. Если новая концепция выпускается вживую, у UX-исследователей нет хорошего способа наблюдать за тем, как люди ее используют, задавать им вопросы и получать обратную связь, необходимую UX, чтобы определить, готово ли что-то или требуется еще одна итерация. UX всегда хочет знать почему, качественно, а не только что или сколько. Как пользователи тратят, конвертируют, вовлекают и т. д.? Избегание надлежащего UX-тестирования усложняет диагностику и устранение проблем или болевых точек клиентов.
4. UX-тестирование окупается. UX-тестирование не требует огромных затрат. Некоторые сторонние инструменты тестирования требуют менее 100 долларов на участника тестирования, некоторые требуют минимального ежегодного обязательства в размере тысяч долларов. Это небольшие расходы, учитывая общий бюджет компании на процесс разработки программного обеспечения и важность ранней обратной связи по тестированию. Раунды пользовательского тестирования почти всегда обходятся дешевле и выполняются быстрее, чем заставлять программистов создавать что-то, что нам, возможно, придется отменить или построить заново.
5. Пользовательское тестирование решает аргументы. Если ваша компания не позволяет специалистам по UX принимать окончательное решение о дизайне продукта, вы можете столкнуться с конфликтом UX с продуктом, разработкой или заинтересованными сторонами, когда существуют разные идеи о том, что должно быть создано и выпущено для пользователей. клиент. Или что, если у UX есть две сильные идеи, и им интересно, какая из них лучше взаимодействует с клиентами? Решение здесь — пользовательское тестирование.

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

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

Это не ориентированный на пользователя дизайн без участия пользователя. Это означает, что мы проводим исследования и тестируем на реальных или архетипических клиентах, а не строим догадки, предположения или «просто отправляем». Мы должны убедиться, что то, что мы «просто отправляем», проверено пользовательским тестированием и является отличным воплощением отличной идеи.

Что происходит, когда UX обходят или уменьшают?

Skype недавно объявил, что его редизайн 2017 года, направленный на то, чтобы сделать его более похожим на Snapchat, потерпел неудачу. Пользователи не хотели, не нуждались и не любили новые функции. Реакция была настолько велика, что Skype объявил в 2018 году, что они снова изменят дизайн Skype. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

Эксперты по UX знали бы на многих этапах своего процесса, что эти функции, вероятно, будут нежелательными или не работают. Исследования с целевыми пользователями могли бы быстро показать, что они не хотят, чтобы Skype стал Snapchat. Закрытие проекта или поворот на таком раннем этапе могли бы сэкономить Skype миллионы долларов, плюс плохие отзывы в прессе и отчуждение клиентов.

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

Гибкий UX-процесс

Помните принципы Agile-манифеста. Ваш наивысший приоритет — удовлетворение потребностей клиентов путем создания ценного программного обеспечения. Предоставьте (UX) работникам среду и поддержку, в которых они нуждаются, доверив им выполнение работы. Максимально увеличить объем невыполненной работы. Постоянное внимание к хорошему дизайну повышает гибкость.

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

Не смотрите на это как на «Большой дизайн вперед» (BDUF), термин, предназначенный для того, чтобы заставить людей съеживаться и заявлять, что это то, от чего мы должны уйти. Когда проект или функция большие или новые, UX необходимо пройти через большую часть, если не весь, процесс проектирования, ориентированный на пользователя. Для UX наименьшая возможная часть более крупной функции — это рабочий процесс или процесс пользователя. Если мы проектируем и тестируем что-то меньшее, мы рискуем, что не получим полной картины истинного взаимодействия с пользователем.

Например, если мы разрабатываем процесс, в котором пользователи регистрируются и совершают покупки, мы не можем просто разработать поля для выбора пароля и передать их инженерам. Если бы UX работал небольшими частями, когда бы тестировался весь процесс? Мы не можем знать реакцию пользователя на весь поток без тестирования всего потока… это означает, что весь поток должен быть разработан до того, как он будет отправлен на тестирование удобства использования.

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

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

UX-практик — часть Agile-команды

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

Назначайте вопросы, неясности или ошибки своему товарищу по команде UX в JIRA или любой другой системе отслеживания ошибок, которую вы используете. Убедитесь, что проблемы UX находятся в той же системе, что и другие проблемы; не оставляйте проблемы с UX на доске Trello, если вы используете VersionOne для всего остального.

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

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

Измерение результатов

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

• Меньше жалоб
• Лучшие обзоры приложений
• Более высокие рейтинги приложений
• Меньше заявок в службу поддержки
• Меньше звонков в колл-центр
• Более позитивная семантика социальных постов
• Больше установок приложения, меньше удалений
• AOV (средняя стоимость заказа) увеличивается
• Более высокий коэффициент конверсии

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

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

Agile UX — это инвестиция, которая более чем окупается

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

Эрик Райс, автор книги «Бережливый стартап », спрашивает: «Что, если мы создадим то, что никому не нужно? В таком случае какое значение имело то, что мы сделали это вовремя и в рамках бюджета?» Даже если ваша организация не использует методологию Lean, предупреждение остается в силе. Желаемые результаты DevOps отражают это, когда мы стремимся создать то, что нужно клиенту, повысить его удовлетворенность и разработать функции с высокой ценностью для клиента.

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