Автор: Саша Окунев Уровень: для начинающих
Эта тема для меня особая, поскольку писать доки — моя страсть. Я люблю и умею собирать требования. Хлебом не корми, дай причесать списки сценариев, написать статьи о терминах и их свойствах. В общем, люблю всё то, от чего другие дизайнеры засыпают и вешаются. В этой серии я буду делиться своими лайфхаками и подходами, которые облегчили жизнь мне и моей команде.
Эта статья даст общее представление о том, зачем писать документацию и почему это важно для дизайнеров интерфейсов.
Бывают несколько понятий со словом «аналитика», которые стоит отличать друг от друга:
Бизнес-аналитика — сбор и анализ данных о том, как работает продукт с точки зрения бизнеса и заработка денег. Это всегда про деньги и нишу продукта: какова финмодель, объём рынка, верхнеуровневая стратегия. Бизнес-аналитика даёт дизайнерам широкий контекст. Ей мы заниматься не будем, потому что это задача продактов, бизнес-аналитиков и топ-менеджмента.
Продуктовая аналитика — сбор и анализ данных о том, как работает продукт с точки зрения интерфейса. Это большая область, которая делится на две: количественную и качественную. Количественная аналитика — это анализ метрик. Анилитики данных делают выводы, которые помогают принимать верные решения в бизнесе и дизайне. Качественная аналитика это интервью с пользователями, наблюдение за их действиями и отчёты о проведённых исследованиях.
Цель продуктовой аналитики — выявить и описать проблемы продукта, которые могут быть решены через дизайн, и упаковать их в понятные задачи для команды. Под дизайном здесь понимаем проектирование новых интерфейсных решений или улучшение существующих. Решая проблемы дизайном, мы улучшаем продуктовые метрики, делаем пользователям хорошо, стремимся делать наш продукт более эффективным и качественным.
Системная аналитика — сбор и анализ данных о том, как работают IT-системы в корпорации. Более техническая дисциплина, которая интересуется тем, какие системы есть внутри IT-контура. Системные аналитики рисуют блок-схемы, которые помогают понять, как всё тикает. Они могут сказать, какие в этих системах хранятся данные и как их можно использовать в интерфейсах. В моём подходе системная аналитика неотделимо переплетается с продуктовой, потому что не зная возможности и ограничения бэкенда, мы не можем выдать качественное дизайн-решение.
Хорошо, когда в документации проекта представлена продуктовая и системная аналитика. Это даёт понимание интерфейса на всех уровнях: от описания общей проблемы пользователей до пользовательских сценариев, названий мастер-систем со ссылками на их документацию.
Документация — это зеркало, в котором отражается весь проект и любые нюансы, которые мы находим важными для него.
Онлайн-документация является важной частью аналитики. Она даёт прозрачную картину всей команде и напрямую влияет на решения дизайнера. Это фундамент, на котором строится следующий этап работы над проектом — проектирование пользовательского опыта.
Без документированных процессов и договорённостей никакая серьёзная разработка продукта невозможна. Требования и артефакты должны храниться в порядке и быть доступны всей команде по первому запросу. Это решает важную стратегическую задачу: вся команда находится в одном информационном поле и может искать по внутренним документам, не дёргая друг друга. Когда в команду приходят новые игроки, им легко вникнуть в доки, поскольку они актуальны и написаны понятным языком. За пару дней можно освоиться в них и быстро начать приносить пользу проекту. В противном случае онбординг нового человека может затянуться на месяцы.
Ещё одна причина — размытие экспертизы. Когда люди уходят из компании, они уносят с собой уникальные знания о продуктах и системах. Документация сохранит знания в команде, даже если все игроки постепенно сменятся.