Визуальное исследование поисковой выдачи Tokyo hotels

Проект исследует не туристический образ Токио и не качество конкретных отелей, а то, как выглядит сама поисковая выдача жилья. В датасете собраны карточки объектов, связанных с проживанием и сервисами: отели, гостевые дома, хостелы, love hotels, капсульные отели, апартаменты, японские гостиницы и часть категориального шума. Поэтому главный вопрос проекта сформулирован не как «где лучше остановиться», а как «каким карточкам в выдаче можно доверять и почему».

Итоговая визуальная метафора — hotel search OS. Город представлен не как маршрутная карта, а как интерфейс выбора: карточки, фильтры, рейтинги, количество отзывов, предупреждения и индикаторы полноты данных. Такой подход лучше соответствует структуре CSV: в нём есть категории, районные поля, рейтинг, число отзывов, телефон, URL и адресные признаки, но нет координат, цен, дат отзывов и текстов отзывов.

Исходный файл tokyo_hotels_dataset.csv содержит 764 объекта и 12 колонок. Основные поля: название, рейтинг, число отзывов, адресные компоненты, городская единица, телефон, категория, вторичная категория и URL. Полных дублей в датасете нет, но есть повторяющиеся названия, которые могут относиться к разным карточкам или филиалам.

Ключевая особенность датасета — смешанность выдачи. Внутри корпуса есть классические hotels, guest houses, hostels, love hotels, capsule hotels, Japanese inns, apartments, а также нерелевантные или пограничные категории вроде hair salons. Это не ошибка, которую нужно скрыть, а важный вывод: поисковая среда смешивает разные типы объектов и требует от пользователя фильтрации.

Ограничения данных были зафиксированы до визуализации. В CSV нет цен, поэтому нельзя анализировать value-for-money. Нет дат отзывов, поэтому нельзя строить сезонность или динамику спроса. Нет координат, поэтому точная карта была бы некорректной. Нет текстов отзывов, поэтому нельзя честно объяснять причины рейтингов через sentiment или complaints. Проект строится только на тех сигналах, которые действительно присутствуют в данных: категория, городская единица, рейтинг, количество отзывов и заполненность карточки.

Работа началась с аудита CSV: были проверены размеры таблицы, типы колонок, пропуски, дубликаты, числовые диапазоны, категориальные поля и пригодность каждого признака для визуализации. После этого проект был переориентирован с туристической темы на UX-анализ выдачи.

Для графиков использовался Python. Первые версии оказались недостаточно удачными: они выглядели как набор похожих карточек и не давали полноценного UI/UX-ощущения. После проверки была собрана новая система: каждый график получил отдельную роль в сценарии выбора жилья. Один показывает состав выдачи, второй — плотность по локациям, третий — доверие к рейтингу, четвёртый — различие форматов проживания, пятый — полноту данных.

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

Первый блок показывает состав выдачи по типам размещения. Он нужен, чтобы сразу снять ложное ожидание: датасет Tokyo hotels не состоит только из отелей. Внутри есть несколько форматов проживания и заметный категориальный шум. Это задаёт главный UX-конфликт проекта: пользователь видит не чистую витрину отелей, а смешанную систему карточек.

Визуально этот блок сделан как inventory-экран: круговая структура показывает доли, а список категорий работает как фильтр выдачи. Такой формат связывает аналитику с интерфейсом поиска.

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

Этот график отвечает на вопрос, где выдача наиболее насыщена. Он не говорит, что район лучше или хуже; он показывает, где в данных больше предложений.

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

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

Четвёртый блок сравнивает форматы проживания по нескольким признакам: средний рейтинг, медианное число отзывов, наличие фото, описания и общая заполненность карточки. Это не просто таблица, а decision matrix: пользователь видит, что разные форматы сильны по разным сигналам.

Например, один тип может иметь высокий рейтинг, но слабую отзывную массу; другой — много отзывов, но менее устойчивую оценку. Поэтому задача проекта — не назвать один «лучший» формат, а показать структуру компромиссов.

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

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

Финальная система построена как тёмный UI/UX-постер с ночным Токио, неоновыми акцентами, карточками, фильтрами и информационными панелями. Палитра основана на глубоком navy, холодных синих тонах, тёплом оранжевом свете Tokyo Tower и ярких signal-цветах для категорий и warning-состояний.

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

Обложка проекта сделана отдельно от инфографики и не содержит текста. Её задача — передать метафору hotel search OS без прямого повторения постера: ночной город, карточки жилья, интерфейсные слои и ощущение поиска. Она работает как визуальный вход в проект, а не как уменьшенная копия финальной инфографики.

Финальная инфографика называется «Как искать жильё в Токио». Она собирает пять аналитических блоков в единый вертикальный UI/UX-постер. Главная идея вынесена в нижний вывод: выбор жилья зависит не только от рейтинга, но и от доверия к карточке — полноты описания, количества отзывов и типа размещения.

Важное ограничение: инфографика, собранная через Image Generation, работает как визуальный постер и презентационный артефакт. Для строгой проверки чисел в проекте также сохранены Python-графики и Colab-файлы, которые воспроизводят расчёты по исходному CSV.

Для проекта подготовлены три отдельные сцены, каждая — самостоятельный мокап, без коллажа и без объединения в presentation board.

Первый мокап показывает общий вид носителя: инфографика висит как крупный framed poster в спокойном интерьерном пространстве. Он демонстрирует, как постер работает как физический объект.

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

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

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

Отдельной частью процесса стала критика неудачных вариантов. Ранние графики и мокапи были отклонены, потому что повторяли один и тот же карточный шаблон, выглядели слишком generic или смешивали несколько носителей в один коллаж. Финальная версия была пересобрана вокруг более чёткой UI/UX-логики.

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

Главный результат — полноценный визуальный кейс.