Цифровой продукт и интерфейс: как пользователь взаимодействует с системой

Когда человек открывает интернет-магазин, Telegram-бота, банковское приложение или CRM, он видит только часть системы.

Пользователь взаимодействует с кнопками, формами, страницами и сообщениями. За ними могут находиться:

• клиентское приложение;
• сервер;
• база данных;
• API;
• внешние сервисы;
• правила доступа;
• бизнес-логика.

Чтобы понимать цифровой продукт, полезно разделить три уровня:

Продукт - какую задачу решает система
Интерфейс - как с системой взаимодействуют
Реализация - какие компоненты выполняют действие

Например:

Продуктовая задача - заказать товар
Интерфейс - карточка товара и кнопка «Купить»
Реализация - frontend, API, backend, база данных и платёжный сервис

Пользователю не обязательно знать устройство реализации, чтобы использовать продукт. Интерфейс отделяет внутреннее устройство системы от способа взаимодействия с ней.

Что такое цифровой продукт

Цифровой продукт - программная система, которая помогает пользователю выполнять определённые задачи или получать цифровой результат.

Примеры:

• интернет-магазин;
• CRM;
• мобильный банк;
• поисковая система;
• образовательная платформа;
• сервис доставки;
• редактор документов;
• Telegram-бот;
• SaaS-система;
• личный кабинет.

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

Сайт - форма реализации
Мобильное приложение - форма реализации
Telegram-бот - форма реализации
Продукт - система, решающая пользовательскую задачу

Один продукт может иметь несколько интерфейсов.

Например, сервис доставки может предоставлять:

Мобильное приложение - клиентам
Веб-панель - ресторанам
Приложение - курьерам
Админ-панель - сотрудникам
API - партнёрам

Это разные способы взаимодействия с одной продуктовой системой.

Пользовательская задача

Проектирование начинается не с кнопки.

Сначала существует потребность или задача.

Например:

Пользователь хочет узнать статус заказа

Из неё появляется функция:

Показать текущий статус заказа

Затем определяется интерфейс:

Раздел «Мои заказы» - карточка заказа - поле «Статус»

И только после этого появляется техническая реализация:

Frontend запрашивает заказ - backend проверяет пользователя - база возвращает статус - frontend показывает результат

Общая цепочка:

Потребность - задача - функция - интерфейс - реализация - результат

Пользователь и роль

У продукта может быть несколько типов пользователей.

Например, в интернет-магазине:

Покупатель - выбирает и заказывает товар
Менеджер - обрабатывает заказ
Администратор - управляет системой

Одна и та же сущность может выглядеть для них по-разному.

Покупатель видит:

Номер заказа - состав - стоимость - статус

Менеджер дополнительно может видеть:

Контактные данные - историю обработки - служебные комментарии

Интерфейс зависит от пользовательской роли и доступных ей действий.

Что такое функция продукта

Функция - возможность системы, которая позволяет выполнить действие или получить результат.

Примеры:

Создать заказ
Оплатить
Отменить заказ
Загрузить документ
Найти клиента
Отправить сообщение

Функция не равна кнопке.

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

Функция - создать заказ
UI-элемент - кнопка «Оформить»
Backend-операция - создание записи и выполнение бизнес-правил

Одна функция может запускаться через разные интерфейсы:

Web UI
Мобильное приложение
API
CLI
Автоматический workflow

Пользовательский сценарий

Пользовательский сценарий описывает последовательность действий для достижения результата.

Например:

Открыть каталог - выбрать товар - добавить в корзину - указать адрес - подтвердить заказ - получить номер заказа

Это уже не одна функция, а цепочка состояний и действий.

Сценарий должен учитывать не только успешный путь.

Товар закончился
Платёж отклонён
Адрес не найден
Соединение потеряно
Пользователь передумал

Поэтому продуктовый сценарий состоит из переходов между состояниями.

Что такое интерфейс

Интерфейс - определённый способ взаимодействия двух сторон.

Сторонами могут быть:

Человек и программа
Программа и программа
Компонент и компонент
Устройство и устройство

Интерфейс определяет:

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

Главная идея:

Интерфейс скрывает внутреннее устройство системы и предоставляет установленный способ работы с ней.

Пользователь кнопки не обязан знать, какие функции Python вызываются на сервере.

Программа, вызывающая API, не обязана знать структуру классов внутри backend.

Интерфейс как контракт

У интерфейса есть ожидаемое поведение.

Например, форма входа обещает:

Ввод - email и пароль
Действие - отправить данные
Успех - открыть систему
Ошибка - сообщить о проблеме

API endpoint тоже является интерфейсом.

POST /orders

Его контракт может определять:

Вход - JSON заказа
Успех - созданный заказ
Ошибка - код и описание проблемы

В обоих случаях одна сторона не обязана знать внутреннюю реализацию другой.

Виды интерфейсов

GUI

GUI - Graphical User Interface, графический пользовательский интерфейс.

Взаимодействие происходит через:

• кнопки;
• окна;
• формы;
• меню;
• карточки;
• таблицы;
• графики.

Большинство сайтов и мобильных приложений используют GUI.

CLI

CLI - Command-Line Interface.

Пользователь взаимодействует через текстовые команды.

python manage.py migrate

Команда является частью интерфейса программы.

API

API - Application Programming Interface.

Он предназначен прежде всего для взаимодействия программ.

GET /orders/42

Клиент знает контракт запроса и ответа, но не устройство серверного кода.

Web UI

Web UI - пользовательский интерфейс, доступный через браузер.

Он строится из веб-технологий и взаимодействует с сервером по сети.

Аппаратный интерфейс

Термин «интерфейс» используется и за пределами программного обеспечения. Общая идея остаётся той же:

Сторона A - установленный интерфейс - сторона B

UI и UX

UI и UX связаны, но описывают разные стороны продукта.

UI - из каких элементов состоит пользовательское взаимодействие
UX - какой опыт получает пользователь при прохождении сценария

Например:

Кнопка «Оплатить» - UI
Понимает ли пользователь итоговую сумму до оплаты - UX

Другой пример:

Поле ввода адреса - UI
Насколько легко найти правильный адрес и исправить ошибку - UX

Красивый UI не гарантирует хороший UX.

Интерфейс может выглядеть аккуратно, но заставлять пользователя:

• делать лишние шаги;
• искать функцию;
• повторно вводить данные;
• угадывать причину ошибки.

Информационная архитектура

До визуального оформления нужно определить, как информация организована.

Информационная архитектура отвечает на вопросы:

Какие разделы существуют
Какие данные относятся друг к другу
Как пользователь переходит между разделами
Где находится нужное действие

Например:

Личный кабинет
├── профиль
├── заказы
│   ├── активные
│   └── завершённые
└── способы оплаты

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

Состояние интерфейса

Интерфейс существует не в одном виде.

Даже экран списка заказов может иметь состояния:

Loading - данные загружаются
Success - данные получены
Empty - данных нет
Error - произошла ошибка

Для отдельного действия могут существовать:

Idle - действие ещё не началось
Loading - запрос выполняется
Success - операция выполнена
Error - операция завершилась ошибкой
Disabled - действие сейчас недоступно

Если разработать только состояние успеха, продукт будет неполным.

Loading state

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

Интерфейс должен показать, что запрос выполняется.

Иначе пользователь может:

• нажать кнопку несколько раз;
• решить, что система зависла;
• закрыть страницу;
• повторить операцию.

Loading - действие принято, результат ещё ожидается

Empty state

Пустой список - отдельное состояние.

Вместо пустого экрана интерфейс может объяснить:

Почему данных нет
Что можно сделать
Как получить первый объект

Error state

Ошибка должна объяснять дальнейшее действие.

Недостаточно показать:

Ошибка 500

Пользовательское сообщение и технический лог решают разные задачи.

Пользовательское сообщение - что делать человеку
Технический лог - что произошло внутри системы

Disabled state

Иногда действие существует, но сейчас недоступно.

Кнопка «Оплатить» недоступна, пока не выбран способ оплаты

Недоступность должна быть связана с понятным правилом.

Клиент и сервер

В сетевом взаимодействии клиент инициирует запрос, а сервер его обрабатывает.

Клиент - отправляет запрос
Сервер - принимает запрос и возвращает ответ

Клиентом может быть:

• браузер;
• мобильное приложение;
• другой backend;
• скрипт;
• устройство.

Сервер - роль в конкретном взаимодействии, а не обязательно отдельный физический компьютер.

Frontend и backend

Frontend - часть приложения, которая работает на стороне пользовательского клиента и отвечает за взаимодействие с человеком.

Backend - серверная часть, которая принимает запросы, выполняет правила и работает с данными.

Пользователь - frontend - HTTP/API - backend - база данных

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

Что происходит после нажатия кнопки

Пусть пользователь нажимает:

Создать заказ

Интерфейс показывает одну кнопку, но за действием может находиться длинная цепочка.

1. Браузер получает событие нажатия.
2. Frontend собирает данные формы.
3. Выполняется клиентская проверка.
4. Формируется HTTP-запрос.
5. Backend принимает запрос.
6. Проверяется пользователь.
7. Проверяются права.
8. Валидируются данные.
9. Выполняется бизнес-логика.
10. База данных изменяется.
11. Backend формирует HTTP-ответ.
12. Frontend получает ответ.
13. Интерфейс переходит в новое состояние.

Общая схема:

Действие пользователя - UI - frontend - API - backend - данные - ответ - новое состояние UI

Эта цепочка связывает продуктовую функцию и техническую реализацию.

Форма как интерфейс данных

Форма позволяет пользователю передать структуру данных системе.

Например:

Имя
Телефон
Адрес
Комментарий

У каждого поля есть несколько уровней правил.

UI - как вводить
Frontend - ранняя проверка
Backend - окончательная проверка запроса
База - ограничения целостности

Нельзя считать значение правильным только потому, что форма в браузере его проверила.

Ошибки на разных уровнях

Не все ошибки происходят в одном месте.

Frontend validation error - значение отклонено до отправки
HTTP error - сервер вернул неуспешный статус
Business error - операция запрещена правилами
Network error - ответ не был получен
Unexpected error - произошёл непредвиденный сбой

Интерфейс преобразует технический результат в понятное состояние.

Серверное состояние и состояние интерфейса

На экране отображаются данные, которые могут существовать на сервере.

Например, в базе:

status = "paid"

Frontend может показать:

Оплачен

Важно различать:

Server state - фактические данные системы
UI state - состояние интерфейса

Например:

Заказ оплачен - server state
Окно подробностей заказа открыто - UI state

Они могут изменяться независимо.

API как программный интерфейс продукта

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

Для человека:

Кнопка «Создать заказ»

Для программы:

POST /orders

Оба интерфейса могут запускать одну бизнес-операцию.

UI - интерфейс для человека
API - интерфейс для программы
Backend-операция - общая логика продукта

Бизнес-правило не должно существовать только внутри frontend, если ту же операцию можно вызвать другим способом.

Что такое интеграция

Интеграция - организация взаимодействия между независимыми системами.

Например:

Интернет-магазин - платёжный сервис
CRM - телефония
Сайт - система аналитики
Backend - сервис доставки

API является одним из механизмов интеграции, но не единственным.

API - запрос по инициативе клиента
Webhook - событие по инициативе отправителя
Очередь - передача сообщений
Файл - пакетный обмен

Продукт не равен интерфейсу

Экран является только представлением возможностей продукта.

Например, банковский перевод включает:

Форму - проверку пользователя - проверку счёта - бизнес-ограничения - изменение данных - запись операции - аудит - уведомление

Удаление кнопки из интерфейса не обязательно удаляет функцию из системы.

Если API всё ещё позволяет операцию, она продолжает существовать.

Интерфейс не является защитой

Если пользователь не видит кнопку удаления, это ещё не означает, что удаление запрещено.

Запрос можно отправить вручную.

Скрытая кнопка - решение UI
Проверка permission - решение безопасности

Frontend может показывать только доступные действия, но backend проверяет права независимо.

MVP

MVP - минимальная версия продукта, позволяющая проверить основную ценность или ключевой сценарий.

Минимальный не означает некачественный.

MVP - ограниченный набор законченных функций
Не MVP - сломанная реализация большого набора функций

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

Feature

Feature - отдельная возможность продукта.

Например:

Сохранить товар в избранное

Она может затрагивать сразу несколько технических компонентов:

UI-кнопка - frontend state - API endpoint - backend - таблица избранного - повторное получение данных

Поэтому продуктовая функция и технический компонент находятся на разных уровнях.

Несколько интерфейсов одного продукта

Один backend может обслуживать несколько клиентов.

Web UI
Mobile app
Admin panel
Partner API
Telegram bot

Все они могут работать с одной предметной областью.

Например:

Web UI - клиент оформляет заказ
Mobile app - клиент отслеживает заказ
Admin panel - менеджер меняет статус
API - партнёр создаёт заказ автоматически

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

Как проектировать функцию от общего к частному

Вместо начала с конкретной кнопки полезно пройти уровни.

1. Пользовательская задача.
2. Результат.
3. Сценарий.
4. Доступные действия.
5. Состояния.
6. Интерфейс.
7. Данные.
8. Серверная операция.
9. Ошибки.
10. Права.

Например:

Задача - отменить заказ
Результат - заказ больше не обрабатывается
Действие - «Отменить»
Условие - заказ ещё можно отменить
Состояние - отмена выполняется
Backend - проверка статуса и смена состояния
Ошибка - отмена больше недоступна

Так интерфейс строится вокруг логики продукта, а не наоборот.

Когда нужен отдельный интерфейс

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

Клиент - мобильное приложение
Менеджер - административная панель
Разработчик партнёра - API
Оператор - CRM

Новый интерфейс добавляет:

• разработку;
• поддержку;
• тестирование;
• управление доступом;
• необходимость сохранять согласованное поведение.

Поэтому отдельный интерфейс должен решать отдельную задачу.

Полный путь цифровой функции

Соберём систему целиком.

Пользователь хочет оформить заказ.

Потребность - пользовательский сценарий - UI - событие - frontend - HTTP-запрос - API - backend - бизнес-логика - база данных - HTTP-ответ - новое состояние frontend - результат

Каждая часть отвечает на свой вопрос.

Продукт - зачем существует функция
UX - удобно ли пройти сценарий
UI - как выглядит взаимодействие
Frontend - как интерфейс работает
API - как компоненты обмениваются данными
Backend - какие правила выполняются
База данных - какое состояние хранится

Итог

Цифровой продукт нельзя свести к интерфейсу, а интерфейс нельзя свести к визуальному дизайну.

Основная структура:

Потребность пользователя - задача - функция продукта - пользовательский сценарий - интерфейс - клиент - сервер - данные - результат

Ключевые понятия:

Цифровой продукт - система, решающая пользовательскую задачу
Функция - отдельная возможность продукта
Интерфейс - установленный способ взаимодействия
UI - элементы пользовательского взаимодействия
UX - опыт прохождения сценария
GUI - графический интерфейс
CLI - командный интерфейс
API - программный интерфейс
Frontend - клиентская часть приложения
Backend - серверная часть приложения

Главная идея интерфейса:

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

Главная идея цифрового продукта:

Технологические компоненты имеют смысл только как часть сценария, который приводит пользователя от задачи к результату.