Как правильно описать USE CASES, когда описываешь спеку на разработку UI интерфейса, чтобы команда не приходила потом с 1000 вопросов потом?
У нас есть трекер калорий и него есть классная фича- сканирование штрих-кода для автозаполнения КБЖУ.
Данные по штрих-кодам мы получаем из нескольких источников внешней системы, но агригируем все у себя на бэке.
Тебе поставили задачу - описать требования к UI.
И один из способов это сделать – использовать USE CASES
Классически USE CASE выглядит так:
✔️ Альтернативные/ошибочные потоки,
Теперь применяем это к нашему примеру:
UC‑1 Быстрое добавление продукта по штрих‑коду
Мобильное приложение, Back-сервис.
- Приложение получило разрешение на доступ к камере.
- Устройство подключено к интернету.
1. Пользователь открывает экран «Добавить продукт» и нажимает «Сканер штрих‑кода»;
2. Камера считывает шрих-код и отправляет POST /barcode/scan {code} на Backend;
3. Backend ищет у себя в кэше.
- Если найден, возвращает нутриенты и калории.
- Если не найден, то идет во внешних API.
4. API отвечает 200 OK, Backend нормализует данные, рассчитывает калории по формуле, кладёт результат в кэш.
5. Приложение показывает карточку продукта с БЖУ и кнопкой «Добавить в дневник».
2А. Камера не запустилась — приложение предлагает ввести код вручную;
3А. Внешний API вернул 404 — открывается форма ручного ввода нутриентов;
3B. API отвалилась по таймауту — показывается заглушка «Сервис недоступен», предлагается сфотографировать этикетку;
- При успешном сценарии - продукт сохранён в дневнике, данные кэшированы;
- При ошибках пользователь получил понятный способ продолжить.
Такой подход к описанию постановки можно найти в Гугл, когда ты пытаешься экстренно разобраться, как решить задачу, которую перед тобой поставили, а ты не понимаешь с чего начать, а он предательски тебе выдал "вот классный способ постановки".
❗️А то, что front разработчику вообще не нужно знать, что происходит на стороне back, а back разработчику может и важно, что там делает фронт, но скорее нет = ИЗБЫТОЧНОСТЬ, которая и порождает за собой лишние вопросы со стороны команды.
Так что же важно, когда мы описываем UI?
❗️Я в своей практике использую такой подход: разбиваю USE CASE на шаги и расписываю отдельно действия пользователя, и отдельно - системы, в рамках одного шага.
UC‑1 Быстрое добавление продукта по штрих‑коду
Шаг 1: Сканирование штрих-кода
- Пользователь находится на экране добавления продукта;
- Пользователь нажал кнопку «Сканировать штрих-код».
1. Система считывает штрих‑код и отправляет запрос:
Request: POST /barcode/scan {code} на Backend.
- если данные получены, то перейти к шагу: отображение карточки продукта с БЖУ;
- если данные не пришли, то перейти к шагу: ввод данных вручную.
Используя такой подход аналитик делает свои доки читаемыми и однозначными, что помогает избежать лишних вопросов со стороны команды 🥂
Почему самообучение — не всегда выход?
Когда ты ищешь информацию в инете, то часто она уровня "обыватель".
✖️ неясно, что действительно нужно учить, а что — пустая трата времени;
✖️ нет обратной связи — ты не понимаешь, правильно ли всё усвоил;
✖️ нет структуры и целостного понимания.
✔️ БАЗУ, которая нужна и для работы, и техсобесов,
✔️ Подробные комментарии к домашкам,
✔️ И главное — мой личный опыт и подходы, которые превращают тебя не просто в аналитика, а в незаменимого специалиста, которого ценит команда