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

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

В разделе описываются основные задачи клиента: найти направление, узнать стоимость и даты, сравнить условия и обратиться за уточнениями. Отдельно учитываются потребности сотрудников агентства, которым важно получать понятные запросы и поддерживать актуальность предложений. Анализ этих сценариев помогает не добавлять в прототип функции, которые не нужны целевой аудитории, и делает требования к продукту обоснованными.

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

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

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

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

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

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

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