Сбор требований: введение
📖

Сбор требований: введение

Автор: Саша Окунев Уровень: для начинающих

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

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

Какая бывает аналитика

Бывают несколько понятий со словом «аналитика», которые стоит отличать друг от друга:

  • Бизнес-аналитика — сбор и анализ данных о том, как работает продукт с точки зрения бизнеса и заработка денег. Это всегда про деньги и нишу продукта: какова финмодель, объём рынка, верхнеуровневая стратегия. Бизнес-аналитика даёт дизайнерам широкий контекст. Ей мы заниматься не будем, потому что это задача продактов, бизнес-аналитиков и топ-менеджмента.
  • Продуктовая аналитика — сбор и анализ данных о том, как работает продукт с точки зрения интерфейса. Это большая область, которая делится на две: количественную и качественную. Количественная аналитика — это анализ метрик. Анилитики данных делают выводы, которые помогают принимать верные решения в бизнесе и дизайне. Качественная аналитика это интервью с пользователями, наблюдение за их действиями и отчёты о проведённых исследованиях.

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

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

Что попадает в доки

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

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

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

Зачем нужно писать доки

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

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

Может, отдать это системным аналитикам?

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

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

Кто даёт нам требования

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

Этапы работы над аналитикой

  • Сбор и анализ требований
  • Уточнение и уборка в собранных данных

Этап 1. Сбор и анализ

Собирать требования нужно, чтобы сориентироваться в проекте и сформировать первичную продуктовую аналитику:

  • Какую проблему мы решаем и зачем всё это. А ту ли проблему решаем?
  • Локализовать проблему, чтобы сфокусироваться на ней и отсечь иные сюжеты, которые можно решить в рамках отдельных задач
  • Когда наши дедлайны и каковы будут последствия для бизнеса, если эта задача будет отложена и появится более приоритетная задача.

Этап 2. Уточнение и уборка

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

Уточнять собранные данные нужно, чтобы:

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

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

Не переключайся.

Наверх: /designer/designer