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

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

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

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

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

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

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

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

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

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