Представьте себе прораба на стройке — он хоть и не делает ничего руками, но должен разузнать пожелания клиентов, придумать, как их реализовать, и донести все аспекты будущих работ строителям. При разработке мобильных приложений работа системного аналитика выглядит схожим образом — он не пишет код и не рисует интерфейсы, но от того, насколько точно системный аналитик разработал свои «инструкции», во многом зависит конечный результат.
Меня зовут Мария Горгоц. Я старший системный аналитик в MedTech компании №1 в России — СберЗдоровье. В этой статье я расскажу о том, как у нас в компании выстроена работа системных аналитиков при проектировании новых фич для мобильного приложения.
Процесс получения задачи
Мы стремимся основательно подходить ко всем этапам пайплайна разработки мобильного приложения, в том числе в части зоны ответственности системных аналитиков.
Процесс работы с задачей выстроен следующим образом:
продакт-менеджер прорабатывает идею, формирует определенное верхнеуровневое видение фичи;
первый артефакт (верхнеуровневое видение) передается дизайнеру, который создает макет реализации (экрана или нового компонента);
разработанные макеты после UI-тестов и других проверок передаются системному аналитику.
После этого системный аналитик включается в работу и начинает с верхнеуровневого представления, а именно — с отрисовки всевозможных схем.
Схемы, которые готовят системные аналитики СберЗдоровья
Мы разрабатываем несколько видов схем под разные задачи. Среди них:
карта экранов (Screen Map);
мокапы экранов (Mockups);
карта переходов (Flow Map / User Flow).
Карта экранов
Карта экранов (Screen Map) — визуальная схема, отображающая все экраны мобильного приложения и их иерархию. Она позволяет понять структуру приложения (например, главный экран → профиль → настройки) и дает верхнеуровневое представление о том, что будет происходить в рамках предлагаемого обновления мобильного приложения.
Обычно на карту мы выносим:
существующие экраны;
новые экраны;
экраны из библиотек смежных команд, которые могут быть затронуты обновлением.
Благодаря этому легче понять, какой объем новых компонентов и доработок предстоит выполнить.
После формирования карты экранов можно переходить к детальному описанию экранов, требующих наибольшей доработки или создаваемых с нуля. Для этого мы используем мокапы.
Мокапы экранов
В нашем понимании мокапы экранов (Mockups) — статичные визуальные макеты интерфейсов, которые отображают расположение элементов (кнопки, поля ввода, изображения) и основные состояния экранов (например, пустая корзина vs заполненная).
Кроме прочего, в мокапах мы можем:
комментировать поведение всех элементов;
описывать особенности реализации;
отмечать, по каким элементам происходит переход к другим экранам;
фиксировать, какие методы бэкенда используются для перехода между экранами.
Разработка мокапов экранов помогает нам детально и более аргументированно оценивать масштаб предстоящих работ, в том числе на бэкенде.
Вместе с тем, первых двух артефактов нам иногда бывает недостаточно, поэтому в отдельных кейсах мы также разрабатываем карту переходов.
Карта переходов
Карта переходов (Flow Map / User Flow) — схема, описывающая сценарии перемещения пользователя между экранами. Карта переходов, как правило, состоит из описания триггеров переходов (например, нажатие кнопки «Далее»), условий (если пользователь не авторизован → переход на экран входа), альтернативных путей (ошибки, отмены действий).
Именно карта переходов позволяет верхнеуровнево, без углубления в Figma, понять, какой путь проходит пользователь в рамках конкретной фичи, и зафиксировать его.
Зачем нам эти артефакты
Вся эта работа, создание карт экранов и переходов, а также мокапов экранов позволяет:
визуализировать все переходы пользователя;
указать используемые запросы;
схематично отобразить весь пользовательский путь.
Это дает нам комплексный профит:
позволяет увидеть всю структуру экранов «в одном окне», избежать дублирования и пропущенных элементов;
помогает быстро выявить противоречия в требованиях;
снижает риск багов и конфликтов при разработке;
исключает тупиковые пути и запутанную навигацию;
экономит время и бюджет за счет выработки четких требований к новым фичам мобильного приложения, минимизирующих необходимость последующих доработок.
Но есть и издержки. Так, на разработку этих артефактов нужно время, а в условиях, когда дизайн по какой-то причине нестатичен, корректировка готовых карт и мокапов может требоваться регулярно. Но на фоне получаемых преимуществ эти издержки для нас не критичны.
Описание экранов
После отрисовки схем мы переходим к описанию экранов.
Мы используем несколько форматов описания и делим требования на две логические группы:
требования к интерфейсам;
функциональные требования.
Под требованиями к интерфейсам мы понимаем:
описание экрана;
состояние экрана и элементов на нем;
точки входа на экран;
различие экрана/элемента для разных платформ;
особенности открытия экрана, навигация на экран;
скролл.
К функциональным требованиям относим:
связь с запросами сервера;
цепочки запросов;
логику поведения элементов экрана;
навигацию;
скрытую функциональность.
Чтобы работать с требованиями было комфортно, а описанные нюансы были наглядными и понятными, мы выработали таблицу единого формата, в которой все фиксируем.
Теперь детальнее остановимся на каждой категории требований.
Требования к интерфейсам
В зависимости от сложности и объема предстоящих работ, мы используем два формата описания требований к интерфейсам.
Если доработка небольшая, мы фиксируем только общую информацию об экране, а именно:
название экрана/элемента;
описание экрана;
точки входа на экран;
что влияет на состояние элементов на экране;
требования;
открытые вопросы.
Если же объем предстоящих работ большой, нам важно тщательно детализировать каждый аспект. В таком случае мы подробно прописываем:
описание экрана/элемента (например, метаинформацию экрана, информацию о том, зачем он нужен, какие сценарии реализует);
точки входа на экран — например, с каких страниц возможен переход (от этого может зависеть способ открытия экрана);
состояние экрана и элементов на нем — например, указываем, что при загрузке данных приложение должно показывать состояние с лоадером;
различие экрана/элемента для разных платформ — это важно, поскольку дизайн для iOS и Android может отличаться;
особенности открытия экрана, навигация на экран — то есть, как будет выполняться переход на экран (с другой страницы или из шторки уведомлений);
скролл — каким образом скроллится контент на экране (что остается статичным, а что перемещается).
Функциональные требования
В контексте функциональности мы также фиксируем ряд требований.
Связь с запросами сервера, цепочки запросов. Это может быть:
валидация данных;
запросы, которые выполняются на экране, но в фоне не влияют на контент;
состояния, которые в случае ошибки должны быть отображены пользователю.
Логика поведения элементов экрана. Например, если пользователь кликает на кнопку «Подключить наушники», приложение должно по Bluetooth подключаться к наушникам. Если у приложения нет системного разрешения — его необходимо запросить.
Навигация. Здесь фиксируем базовые описания всех переходов — что именно происходит при клике на каждую кнопку (например, какая страница открывается, какие методы на бэкенде запускаются и так далее).
Помимо этого, мы описываем все, что касается скрытой функциональности в части:
использования локальной БД;
работы с кэшем;
работы с пушами и диплинками;
сбора событий продуктовой аналитики.
Почему для мобильных приложений нужны свои требования
У нас в компании уже есть выработанные и общепринятые требования, с которыми работают все системные аналитики СберЗдоровья. Вместе с тем, возможности и сценарии использования веб-версии отличаются от возможностей приложений для мобильных платформ. Поэтому разработка отдельных требований и способов ведения документации под мобильные приложения — логичная необходимость.
Веб-версия | Мобильные приложения | |
Использование шаблона | Используют 100% аналитиков | Используют 100% аналитиков, но шаблон под мобильные приложения регулярно расширяется |
Использование локальной БД | Данные хранятся на сервере | Данные хранятся на устройстве с синхронизацией |
Кэширование | Используется кэш браузера для скорости загрузки | Кэш приложения используется для обеспечения оффлайн-доступа |
Пуши | Пуши через браузер (редко) | Пуши через ОС с переходом на экран |
Диплинки | Открытие страницы в браузере | Открытие конкретного экрана с обработкой пути назад |
Оффлайн-работа | Нет оффлайн режима | Поддерживается оффлайн-режим с локальными данными |
Форс- и софт-апдейты | Обновления на стороне пользователя | Обновления через магазины приложений |
Различия платформ | Единый стандарт для всех браузеров | Разные гайдлайны для iOS и Android |
Пути назад | Назад через браузер (стандартно) | Назад через кнопку/свайп с описанием |
Карты и мокапы | Редко используются для больших фич | Часто для больших фич для визуализации навигации |
Примечание: В таблице указаны не все отличия между сервисами под разные платформы, а только самые ключевые. Но их достаточно, чтобы понять общие тенденции.
Что в итоге
Мобильная разработка — это не спринт, а марафон. Чтобы не сбиться с пути, нужны карты экранов, переходов, состояний. В СберЗдоровье мы убедились — без артефактов системного аналитика даже гениальный продукт рискует столкнуться с противоречиями. При этом схемы и таблицы требований могут стать удобным «единым источником правды», который синхронизирует команды и страхует от ошибок.
Наш подход не уникален, поэтому может быть внедрен и в других компаниях. Но важно помнить, что мобильные платформы — это отдельная вселенная со своими правилами. Игнорировать их — значит терять пользователей на поворотах.
А пока делитесь в комментариях, как вы описываете требования и какие артефакты разрабатываете для мобильных приложений в своих компаниях?