В разработку цифрового решения вовлечены двое: UX-исследователь и программист. Команды НКО и активисты могут нанимать их для оптимизации своей работы, но непонимание между всеми сторонами процесса может привести к обратному эффекту — неправильному распределению рабочих задач, конфликтам и неудовлетворительному результату работы. Команда «Токио» выделила пять главных проблем, которые могут возникнуть у представителей социальных проектов в работе с UX-специалистами и разработчиками, и предложила варианты их решения.
Отсутствие KPI, целей и задач
Проблема: Представители НКО или социальных проектов часто не имеют представления о специфике решаемых UX-исследователями и разработчиками задач и из-за этого некорректно ставят техзадание. А значит, у специалистов нет четких целей и задач, им не установлены ключевые показатели эффективности (KPI).
Из-за расплывчатости формулировок возможны их разные интерпретации. И если гуманитарная сторона, условно представленная UX-исследователем, еще может верно растолковать абстрактно поставленную задачу, то технический специалист ее вряд ли воспримет. В итоге результат может не соответствовать ожиданиям заказчика.
Решение: Команда НКО или активистов должна сформулировать для себя: 1) проблемы, которые требуется решить с помощью цифровизации; 2) ожидаемые результаты и выгоды. Затем этим качественным данным нужно задать количественную оценку и выделить самые приоритетные и ресурсозатратные.
Пример: Запрос «мы хотим разгрузить бухгалтера». В этом случае в качестве количественных показателей можно использовать рабочее время бухгалтера: сейчас он тратит на обработку документов 14 часов, а после внедрения цифрового решения будет 5.
Техническому специалисту и исследователю стоит сформулировать и обсудить требования друг к другу. Затем — также договориться о предоставлении качественных данных в количественном эквиваленте. Так разработчики и UX-исследователи определяют критерии, по которым придуманное ими решение будет впоследствии оценено.
Непонимание обязанностей
Проблема: Каждая из сторон, вовлеченных в процесс, не понимает, что делает другая. В результате у всех появляются ожидания, которые не оправдываются.
Решение: Определите для себя, что такое UX-исследования и что такое техническая разработка, что делают специалисты по тому и другому. UX-исследователь использует свои знания в области психологии для исследования пользователей и их запросов. Разработчик предлагает цифровое решение, учитывая данные исследования — как поведет себя пользователь при использовании конкретных функций и каковы его ожидания от них.
Поэтому всем сторонам необходимо изучить основы UXR и IT. Когда все участники рабочего процесса знают их и минимальный словарный запас профессиональных терминов этих сфер, им намного легче контактировать.
Если стороны не понимают задачи, обязанности и особенности работы друг друга, это может привести к проблемам. Например, исследователь придумает концептуальное решение, которое оптимально для пользователя, но непрактично для технического специалиста.
Допустим, юзер хочет голосовой поиск в таск-трекере — и исследователь предлагает ответить на этот запрос и добавить такую функцию. Но разработчик не может это сделать, потому что это слишком сложно и дорого — ему не хватает ни времени, ни денег.
Отсутствие документации
Проблема: Иногда ошибки возникают из-за того, что все особенности пользовательского запроса и функциональные возможности недостаточно хорошо задокументированы исследователем и разработчиком. Это приводит к ошибкам, которые придется исправлять позже.
Решение: Всем сторонам следует договариваться и фиксировать на ранних этапах ожидания друг от друга в части используемых методов. Это документ, в котором обозначается, какими методами решается проблема, и прописываются все шаги исследования.
В процессе работы исполнителям надо документировать ее, сохраняя все «артефакты»: интервью, схемы, диаграммы, заметки. Например, исследователь, проводя интервью, должен записывать свои выводы в понятном виде и размещать их в открытый доступ. Все эти документы должны быть написаны на понятном и для разработчика, и для исследователя языке. Для этого лучше всего выбирать способы описания, известные обеим сторонам, например, BPMN, user stories.
О том, где расположены все необходимые документы, необходимо проводить инструктаж. Таким образом, разработчик и исследователь получат всю информацию и представление о том, как они должны работать. В результате этого они смогут сотрудничать в разработке дизайна / технических требований и, возможно, предлагать альтернативные решения разных задач.
Невзаимодействие UX-исследователя и разработчика
Проблема: UX-исследователь и технический специалист не контактируют и не взаимодействуют, а значит, и не сотрудничают.
Решение: Обсуждать совместно промежуточные итоги исследования и разработки. Это не только способствует здоровым рабочим отношениям, но и помогает иметь общую картину в динамике. Здесь можно посоветовать относиться к взаимодействию двух сторон, как к UX-работе — найти потребности второй стороны и согласовать их с потребностями первой и заказчика. Надо определить общие цели и позволить этим целям направлять команду. Тем самым получится обойти любые необоснованные мнения или ошибочные аргументы.
Желаемые результаты, технические проблемы и успехи должны регулярно обсуждаться между разработчиком и UX-исследователем. В противном случае может оказаться, что все слышат и интерпретируют вещи по-разному.
Разработчикам следует участвовать в процессе с самого начала, спрашивать об исследовании и его ходе, а также отвечать на вопросы других специалистов и объяснять, что может быть внедрено, а что нет. В свою очередь, UX-исследователю следует объяснять коллегам теорию максимально доступно и не бояться задавать вопросы, будет ли то или иное предложение работать.
Конфликты между сторонами
Проблема: Большинство людей реагируют на конфликты негативно, что деморализует команду и мешает ее продуктивной работе. В итоге срываются сроки, а результат получается не вполне удовлетворительным.
Решение: Конфликты неизбежны, и вопрос не в том, как их предотвратить, а в том, как с ними работать. Проактивное понимание конфликта и работа с ним могут дать команде больше, чем гармоничная совместная работа без обнаружения острых углов. Например, конфликты могут замедлить принятие решения, но могут и помочь прийти к правильному решению, которое в конечном итоге ускорит процесс.
Умение находить компромисс между двумя командами помогает улучшить результат работы. Роль руководителя в этом случае крайне важна. Он предупреждает и разрешает конфликты, организовывает рабочий процесс и обеспечивает коллаборацию всех специалистов. Его успешная работа гарантирует взаимопонимание между всеми участниками процесса.
Наиболее распространенный тип конфликта — конфликты задач: разногласия по поводу рабочих проблем и их решений. Наилучший способ разрешения этих конфликтов — общение лицом к лицу. Команде стоит вместе определять и обсуждать цели и задачи, KPI, стараться понять роли друг друга и того, как они вписываются в проект реализации задачи. Стоит также вырабатывать правила и культуру сотрудничества, а вместе с тем и позитивное отношение к конфликтам.
Выводы
Главная задача при разработке цифрового решения: найти точки соприкосновения между всеми — заказчиком, исследователем и разработчиком.
Если у вас получится сделать это и избежать всех упомянутых ошибок, вы сможете получить продукт, который:
- создаст отличный пользовательский опыт;
- окажется несложным в разработке;
- будет недорогим и быстрым в создании для НКО / активистов.
А значит, вас можно будет поздравить с успешным результатом.
Материал подготовлен при поддержке «Токио» — команды цифровой трансформации Теплицы социальных технологий. Сейчас многие сервисы закрывают работу с клиентами из России. Команда цифровой трансформации готова бесплатно помочь вашей НКО с настройкой собственного или арендованного сервера и необходимых вам альтернативных open source решений для командной работы.
Заполните заявку для работы с нами.