Практическая магия взаимодействия System Analyst и UX-designer

Екатерина Шагарова

Аналитик Группы «Иннотех»

Привет, меня зовут Катя Шагарова, второй год я работаю аналитиком в «Иннотех» на проектах крупных заказчиков. На текущем проекте мы переносим некоторый старый функционал в канальное приложение одного из партнёров для сотрудников курьерской службы доставки карт. Задача пользователя — сформировать необходимый пакет документов для выезда и выдачи карт. На повестке дня стоит цель не только перенести функционал AS IS, но и улучшить пользовательский опыт, спроектировать простой и понятный пользовательский интерфейс, несмотря на техническую сложность.

Опираясь на опыт коллег, представленный на международной конференции AnalystDays/16, я хотела бы поделиться «Практической магией взаимодействия System Analyst & UX-designer», потому что на своём же примере знаю, что можно столкнуться со сложностями.

Когда возникают конфликты

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

1. Аналитик сам всё спроектировал, принёс дизайнеру, чтобы тот «красиво и удобно» нарисовал. 
2. Дизайнер нарисовал только то, что сказал аналитик, без дополнительных исследований. 
3. Аналитик постоянно отклоняет различные «хотелки» дизайнера, улучшающие пользовательский опыт, ввиду различных технических причин. 
4. Дизайнер имеет типаж «я художник, я так вижу», его интересует только UI, без технических подробностей. 
5. Дизайнер имеет типаж «мне аналитик не нужен, я сам знаю, что «логично», а что нет для пользователей».

При этом всем известно, что аналитик и дизайнер имеют общую цель: «клиентское счастье и качественный продукт». Со счастьем всё более-менее понятно: как минимум это нестрадающий пользователь. А говоря о качестве, можно обратиться к «Табуретке Нормана». Данный подход состоит в том, что все три ножки табуретки — технологии, бизнес и пользовательский опыт — должны быть одинаковой длины.

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

Из-за чего возникают проблемы при взаимодействии

1. Недостаточное взаимопонимание

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

2. Недостаток или избыток информации

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

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

3. Различные цели и приоритеты

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

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

5. Недоверие друг другу.

6. Аналитик полагается только на свой опыт, дизайнер полагается только на исследования.

На какие группы можно поделить проблемы и как их решать

Проблема сбора требований

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

Решение

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

Проблема распределения обязанностей

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

Решение

Нужно установить, какие задачи и области работы относятся к каждой роли. Это поможет устранить путаницу и неопределённость в распределении обязанностей.

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

Любые изменения в распределении обязанностей нужно осуществлять с общим согласием и пониманием между друг другом.

Проблема подхода к продукту

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

Решение

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

Проблема дисбаланса экспертизы и данных

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

Решение

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

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

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

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

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

Как выглядит эффективное взаимодействие

1. Появляется задача.

2. Составляется её описание по выбранному шаблону.

3. Проводится совместное исследование и определение открытых вопросов.

4. Далее и аналитик, и дизайнер разбираются со своим набором вопросов. При этом взаимодействие не прекращается, оно имеет параллельно-совместный характер.

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

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

5. PBR с командой.

Описанное взаимодействие прекрасно вписывается в концепцию SCRUM, поскольку сделано на его основе — трёх столпах эмпиризма — прозрачности, инспекции и адаптации. Работа над задачей начинается как минимум за спринт-два до предполагаемого спринта разработки.

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

Подводим итоги

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

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

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

Бизнес также получит выгоду: повысится уровень удовлетворённости пользователей, улучшится эффективность разработки, инкременты с качественным UX и прогнозируемым выходом в прод, снизятся затраты на исправление ошибок, перепроектирование старых систем не только AS IS, но и сразу с улучшением пользовательского опыта.