{"id":13660,"url":"\/distributions\/13660\/click?bit=1&hash=829c3f4bd5611858ea9456b55832e0254413f056f0bd8b6fa3b9fccae541092c","title":"\u041b\u0438\u0434\u0435\u0440\u044b \u0440\u044b\u043d\u043a\u0430 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442, \u043a\u0430\u043a \u0431\u044b\u0442\u044c \u043b\u0438\u0434\u0435\u0440\u0430\u043c\u0438 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c \u0433\u0434\u0435","imageUuid":"b21a2e96-c2cd-51bd-a6d9-39deeed48e3c","isPaidAndBannersEnabled":false}
Дизайн
red_mad_robot

Оверинжиниринг, требования и макеты: настраиваем коммуникацию аналитики и дизайна

Пять самых популярных «болей» во взаимодействии на этапе проектирования

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

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

Процесс исследовала бизнес-аналитик red_mad_robot Даша Измоденова.

Боль № 1. Сначала дизайн, потом аналитика

Ребята в red_mad_robot привыкли к постоянным изменениям — клиенты, проекты, команда, технологии. Рядовой сотрудник в среднем успевает поработать на четырёх проектах за год. Жить в условиях непостоянства тяжело, поэтому в компании существует закреплённый и проверенный на опыте производственный процесс — описание работы над типовым проектом с разбивкой по ролям и зонам ответственности.

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

Катя Голева, ИО директора производства red_mad_robot Central Asia

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

Сначала аналитик вгружает дизайнера в требования…

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

…а затем дизайнер проектирует макеты

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

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

Лайфхак: на этапе проектирования полезно составлять блок-схему основных сценариев. Мы разработали шаблон такой схемы — можете использовать на своих проектах.

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

  • список параметров, используемых на экране;
  • источник данных (например, API);
  • возможные ошибки при клиент-серверном взаимодействии и способы их обработки.

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

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

Даша Князева, старший дизайнер red_mad_roobot

Почему по готовым макетам нельзя описывать функциональность системы

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

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

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

Боль № 2. Проработка краевых сценариев

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

На старте проекта аналитик собирает нефункциональные и интеграционные требования и рисует High Level Diagram (HLD) — верхнеуровневую схему архитектуры приложения. Если с архитектурой возникают какие-то сложности, на помощь приходят техлид, разработчики и ментор.

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

Дизайнер — особенно новичок — слабо погружён в технические детали, поэтому аналитику стоит ему помочь. Важно помнить, что дизайнер может не знать терминов разработчиков, поэтому отправлять его лично общаться с бэкендерами негуманно.

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

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

Боль № 3. Дизайн и требования не сходятся

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

Как бы это ни звучало, но в red_mad_robot есть свои требования к описанию требований. Они должны быть:

  1. Не привязанными к дизайну. Не стоит описывать поведение конкретных кнопок и элементов интерфейса, вместо этого лучше фиксировать бизнес-требования. За время проектирования дизайн может измениться много раз — требования останутся актуальными.
  2. Корректными. Аналитик должен убедиться, что точно всё правильно понял, когда формулировал требование.
  3. Недвусмысленными. Двойная трактовка требований при прочтении недопустима и приводит к обидным ошибкам.
  4. Полными. Продумано и описано поведение системы при всех возможных сценариях.
  5. Непротиворечивыми. Одни утверждения не должны отрицать другие.
  6. Проверяемыми. Должна быть возможность проверить, что требование выполнено.
  7. Модифицируемыми. Должна быть возможность легко вносить изменения.
  8. Трассируемыми. Требования должны быть пронумерованы с возможностью ссылаться на любой их фрагмент.
  9. Понятными. Вспоминаем принцип Вергилия: пишите не так, чтобы вас поняли, а так, чтобы вас невозможно было не понять.

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

Требования к макетам:

  1. Наличие заголовков, нумерации и подписей к экранам для навигации.
  2. Наличие «карты переходов» — последовательности действий пользователя при каждом сценарии. Переходы показываются стрелками.
  3. Описаны краевые состояния (да-да, ещё раз про них).
  4. Макеты для iOS и Android расположены отдельно друг от друга.

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

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

Так как мы всё-таки не в идеальном мире, требования и дизайн могут расходиться. Вот в каких ситуациях:

  1. Просто так, по вдохновению дизайнера или аналитика. Один придумал решение, внёс изменения и не предупредил другого.
  2. После того как аналитик или дизайнер проконсультировались по сложному вопросу с ментором — старшим и опытным товарищем.
  3. После согласования макетов с клиентом — часто появляются небольшие правки, о которых легко забыть.
  4. После встречи с разработчиками. Например, они оставили комментарии на макетах в Figma, дизайнер их поправил, а аналитик был не в курсе.
  5. Во время разработки — что-то пошло не так, нужно отступить от требований или на ходу применить другое решение.
  6. Внесли изменение для одной платформы, а на другую перенести забыли. Бывает.

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

Боль № 4. Оверинжиниринг

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

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

Ниже — классические примеры оверинжиниринга, с которыми мы иногда встречаемся в работе.

Команда придумала крутые фичи, которых нет в изначальном скоупе

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

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

Иногда клиент хочет видеть на демо не только MVP, но и целевую картинку на развитие. Тогда сделайте две версии вайрфреймов: первую — MVP, вторую — на развитие. И покажите клиенту обе.

Дизайн выглядит слишком дорогим и сложным

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

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

Автоматизация редкого процесса

Допустим, команда разрабатывает сервис электронного документооборота накладными и счетами-фактурами, которые отправляются в утвержденном ФНС формате. Создать документ можно двумя предполагаемыми способами: в онлайн-форме редактора и через загрузку файла. Какой вариант делать первым?

Аналитик сперва должен ответить на вопросы: каким образом пользователи создают эти документы, как часто? В каком формате они создаются? Подходит ли он нам?

Если раскопать ситуацию глубже, выяснится, что большая часть пользователей системы — бухгалтеры, которые несколько раз в день создают закрывающие документы в 1С. А 1С можно быстро доработать таким образом, чтобы формат соответствовал требованиям. Получается, реализовав загрузку документа через файл, бизнес быстро удовлетворит потребность 80% клиентов.

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

  1. Сколько пользователей сталкиваются с проблемой?
  2. Как часто?
  3. Почему это проблема?
  4. Как проблему решают сейчас?
  5. Что случится, если её не решить?

Ответив на них, сравните оценку предлагаемого решения с уже существующим. Стоит ли игра свеч?

Онбординги, тултипы, подсказки…

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

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

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

Боль № 5. Проблемы с коммуникацией

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

Дизайнер и аналитик говорят на разных языках…

«Ввод-вывод данных, приём управляющих команд и отображение результатов их исполнения должны выполняться между пользователем и компьютерной системой в режиме реального времени…»

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

«Я никогда не работала с дизайном, поэтому для меня бывает трудно понимать их профессиональные словечки: сплэш скрины, шиммеры, снек бары… Конечно, можно погуглить или спросить у дизайнера, но иногда такие вещи всплывают на встрече с клиентом, где спрашивать такое не очень уместно. Может, где-то есть глоссарий „дизайнерских слов“? Он бы пригодился».

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

…проговаривают одни и те же вопросы несколько раз…

После изменений в требованиях или макетах необходимо рассказать об этом дизайнеру и аналитику. Если информация передаётся устно, есть большой риск что-то забыть, а значит — потратить время на повторное обсуждение. Проблема решается классической фиксацией договоренностей. Важно выбрать для этого единое место, чтобы потом было проще вернуться. Например, комментарии или стикеры в Figma, Google Документ или канал в Slack.

…и не могут договориться

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

Заключение

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

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

Аня Чебаева, дизайнер интерфейсов red_mad_robot

Поделюсь кейсом. На одном проекте в виду обстоятельств одновременно стартануло два стрима работ: разработка и проектирование. Это создавало ряд сложностей — реализацию Backend и Frontend пришлось вести параллельно с проработкой функциональных требований, созданием вайрфреймов и описанием пользовательских сценариев. В этих условиях аналитика и дизайн объединили усилия: дизайнеры проводили вторичные исследования и собирали черновики макетов, а аналитики уточняли у клиента функциональные требования и совмещали готовый результат с методами на Backend. Командная работа ускорила процесс создания мобильного приложения — мы не ждали готовности Backend для начала проработки UX, а итеративно создавали вайрфреймы и совместно с клиентом уточняли требования, что позволило с минимальными доработками выполнить работу в срок.

Света Широкова, бизнес-аналитик red_mad_robot

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

Если наш опыт оказался полезным, а тебе было интересно читать, что сгенерировали наши нейросети, посмотри ещё и статью, где мы рассказываем о том, как развиваем наши Telegram-каналы по методике кайдзен и набираем подписчиков без рекламы.

Чтобы ничего не пропустить, следи за развитием цифры вместе с нами:

VK

Да пребудет с тобой сила роботов! 🤖

0
4 комментария
Инна М.

Жиза жиз. Правда, на нынешнем месте работы я как дизайнер пишу требования к макетам (и сама же по ним рисую), а также сама общаюсь с разработчиками фронт- и бэкенд, потому что в моей ситуации аналитик мне сказал: "Ты говоришь с разработчиками на одном языке, они тебя лучше понимают, давай ты с ними будешь общаться!"))

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

Ответить
Развернуть ветку
red_mad_robot
Автор

Спасибо за комментарий! Расскажите, удобно ли вам самостоятельно описывать требования к макетам? В каком виде их пишете? И какие задачи на вашем проекте выполняет аналитик?

P. S. Про «вгружение» — принято, это наш местный робосленг.

Ответить
Развернуть ветку
Инна М.

Прописывать требования самой, а также продумывать архитектуру, функционал мне удобно и даже нравится. Потому что так мне легче понять, какие элементы надо использовать и как лучше обернуть тот или иной блок в интерфейсе. На предыдущем месте работы я выполняла функции тупо UI, рисуя макеты по требованиям, которые писал ПМ без моего участия. У меня не было времени вникнуть, что происходит в продукте, как взаимосвязаны отдельные фичи и экраны.
Сейчас чаще всего на созвоне с ПМ и/или аналитиком мне выкладывают устное или письменное очень краткое ТЗ аля "хочу уметь так", а я уже прорабатываю его, продумываю, как сделать и какие элементы использовать, чтобы его выполнить.
В каком виде и как пишу: прикидываю в уме, набрасываю на бумаге, потом в Confluence пишу. Стараюсь писать как можно более подробно и понятно, чтобы человек, не знающий об этом элементе/макете/фиче понял, что происходит и как это дело верстать (потому что разработчикам надо говорить четко и ясно, оттенки серого почти всегда вызывают вопросы).
Насчет аналитиков. Если честно, я не знаю какие задачи они выполняют тут, я работаю с нового года, не знаю всех тонкостей.

Ответить
Развернуть ветку
Инна М.

Я не супер опытный дизайнер, еще не знаю всех подводных камней менеджмента продукта.

Ответить
Развернуть ветку
Читать все 4 комментария
null