Как Experience Design сыграл решающую роль в развитии машинного обучения для программы стажировки Slalom Build

Как дела? Нет, правда?

Если вы похожи на меня, ваша реакция на этот вопрос может меняться в зависимости от уровня стресса, связи или даже погоды. Для такого простого вопроса за этим ожидаемым «хорошо» стоит многое, что нужно распаковать или пропустить.

В рамках подготовки к программе стажировок Houston Slalom Build 2022 перед группой инженеров и дизайнеров была поставлена ​​задача найти лучший способ обеспечить благополучие сотрудников в Slalom. Усилия по открытию возглавили два опытных дизайнера (включая меня) и владелец решения (руководитель проектной группы). Нашей целью было определить решение для анализа данных, которое могли бы разработать новые стажеры. Затем мы задокументировали это предлагаемое решение, чтобы обеспечить более плавную адаптацию стажеров и обеспечить согласованность между двумя их модулями.

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

Положение вещей

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

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

Как мы можем собрать информацию об удовлетворенности сотрудников более осмысленным и измеримым способом?

Нам еще предстояло многому научиться у разных групп. Для нашего заинтересованного лица в Slalom IT, что он надеялся получить от участия, и как выглядел для него успех? Для наших пользователей, сотрудников Slalom, нам нужно было понять, что для них значит значимая работа и благополучие. Как они предпочитали давать свои отзывы и как часто они хотели, чтобы их спрашивали? Только тогда мы могли бы создать что-то, что сотрудники действительно будут использовать.

Выяснение нашего почему

Мы начали со сбора отзывов с помощью вопросов, разосланных через Slalom Build. Учитывая наши сжатые сроки, у нас была всего неделя, чтобы собрать ответы и узнать, что заставляет сотрудников чувствовать себя вовлеченными.

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

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

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

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

Создание источника истины

Чтобы реализовать это решение, команде требовалось общее понимание того, как системы и технологии работают вместе для обеспечения конечного результата. Это понимание будет направлять каждую группу в достижении ее более крупных целей и определять, как они будут работать вместе. Мы создали план обслуживания, начав с ключевых точек взаимодействия пользователя и наметив разговор между сотрудником и чат-ботом. Затем мы расширили наше понимание вспомогательной технологии. На семинарах мы собрали всю команду (владелец продукта, владелец решения, инженеры-программисты, инженеры по данным и дизайнеры) вместе, чтобы внести свой вклад и сообщить нам, что необходимо скорректировать.

Когда семинары были завершены, у нас был задокументированный источник правды о том, что нужно было создать команде. Для исследовательской группы эта схема обслуживания привлекла внимание к что и почему . А для стажеров это встряхнуло их, чтобы они могли сосредоточиться на создании (как). Для модуля разработки программного обеспечения (SE) это означало понимание того, какие API необходимо создавать. Для модуля обработки данных (DE) это соединило точки в отношении того, какой тип информации необходимо использовать и как она будет визуализирована для руководства.

Настройка потока беседы

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

Возможные форматы для типовых вопросов включают:

  • Верно/Неверно
  • Шкала 1–10
  • Ввод текста
  • Большой выбор
  • Реакция эмодзи

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

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

Имея в руках артефакты направления и открытия, стажеры смогли выйти за рамки ожидаемого MVP. Наряду с панелью мониторинга Power BI и моделью машинного обучения команда стажеров также разработала полностью работающее доказательство концепции. Этот POC оказался неоценимым для создания импульса и заинтересованности во время групповых демонстраций, демонстрируя, как несколько разговоров будут выглядеть и восприниматься сотрудниками в Slack.

Лучше, быстрее, сильнее

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

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

Вы можете узнать больше о том, как Slalom Build подходит к интеллектуальным продуктам здесь. Для статей по теме ознакомьтесь с Human-Centered API.