Концепт · Рабочий веб-прототип · 2026
Leeway помогает пассажирам спланировать приезд в аэропорт Бен-Гурион: заранее забронировать окно для досмотра и следить за своим продвижением по аэропорту.
Концептуальный проект. Прототип работает в любом браузере, но не подключён к системам бронирования и безопасности аэропорта.
01 Задача
В Бен-Гурионе вылетающие пассажиры проходят короткое интервью службы безопасности прямо на входе в терминал, ещё до регистрации. Его длительность трудно предсказать, поэтому большинство просто приезжает за три часа. Leeway заменяет эту догадку забронированным окном.
«Я всегда приезжаю в аэропорт примерно за три часа до вылета».Респондентка 4 (перевод с иврита)
02 Исследование и направление
Четыре интервью указали на одно и то же: пассажиры не могут знать, сколько времени займёт аэропорт, и приезжают пораньше на всякий случай.
За 2,5–3,5 часа до вылета, каждый раз.
Ответ в дизайнеОкна строятся от времени вылета рейса.
В одной поездке это досмотр, в следующей — регистрация.
Ответ в дизайнеБронируется только досмотр. Регистрация показана, но не обещана.
Паспорт и посадочный талон на стойке.
Ответ в дизайнеQR показывают вместе с документами, а не вместо них.
Подсчёт по четырём реальным интервью. Четыре смоделированных сценария использовались только чтобы отметить допущения. Методология
Основная персона
Однажды потерял больше часа, когда закрыли стойку. С тех пор всегда приезжает за три часа. Ему не хватает контроля, а не терпения.
Вторичная персона
Планирует своими инструментами. Дольше всего она ждала на регистрации, поэтому Leeway помогает ей меньше всех.
Оценки (1 — раздражение, 5 — мотивация) — мои сценарные оценки из упражнения с картами пути, построенные на исследовании персон. На участниках они не измерялись.
Leeway бронирует досмотр и сопровождает пассажира до конца регистрации. Регистрация показана как следующий этап без зарезервированного времени, потому что её длительность зависит от того, что забронировать нельзя.
03 Дизайн Leeway
Один выбор при бронировании, главный экран, который следует за поездкой, и подтверждение, которое работает под давлением.
A · Бронирование
В первых вайрфреймах было два выбора: окно для досмотра и окно для регистрации. Второе я убрал: после досмотра, длительность которого непредсказуема, окно регистрации было бы догадкой под видом брони.
Теперь экран предлагает девять окон по 20 минут, построенных от времени вылета. Последнее заканчивается за два часа до вылета.
B · Отслеживание
Главный экран сохраняет одну раскладку, но карточка статуса меняется вместе с состоянием пассажира, поэтому следующее полезное действие всегда очевидно.
C · Доступность
На стойке QR открывается на весь экран одним касанием, а оболочка приложения кешируется, поэтому оно загружается и без связи.
Многие пассажиры не читают на иврите, поэтому интерфейс работает на иврите, английском, арабском и русском, с раскладкой справа налево там, где нужно. Переключатель языка — на главном экране, где его найдёт тот, кто не может прочитать интерфейс.
Визуальный язык
Из четырёх направлений я отложил самое игривое: весёлый тон не подходил к самому напряжённому моменту пути.
04 Взаимодействие и прототип
Рабочий прототип на HTML, CSS и JavaScript. Пройдите основной сценарий, а потом попробуйте сами.
Снято с прототипа. Карточка рейса использует пример записи о вылете; доступность окон смоделирована.
Введите реальный рейс из Бен-Гуриона на ближайшие дни, и окна рассчитаются от его времени вылета.
05 Итоги и рефлексия
Я наблюдал, как до семи человек пробуют прототип, неформально. Их реакции привели к этим изменениям.
Пустое поле раньше открывало целый экран ошибки, и люди терялись. Теперь форма отмечает, чего не хватает, прямо на месте.
После: поля, которые нужно исправить, отмечены на месте.
В первом раунде были полоса дат и окна на всё утро. Итоговая сетка показывает только девять, которые подходят к рейсу.
После: окна строятся от времени вылета.
Люди спрашивали, что именно они бронируют. Подсказка при первом входе теперь указывает на настоящие элементы.
Часть тестировщиков не читает на иврите. Это изменение повлияло сильнее всех остальных.
Поле теперь принимает форматы неизраильских паспортов.
Первая сборка зафиксировала примерные окна из Figma: рейсу в 21:10 предлагалось окно в 6:40. Теперь правило живёт в одном месте кода.
Один бронируемый этап сохранил сценарий коротким и помог убрать лишние экраны.
Значение в макете может быть примером или правилом. Теперь я помечаю, что есть что, до того как что-то строить.
Приложение
Полные исследовательские доски, методология и заметки о реализации — для тех, кто хочет глубже.
Я проинтервьюировал четырёх человек. Параллельно написал четыре смоделированных интервью, чтобы проверить допущения, о которых было некого спросить: частый бизнес-путешественник, родитель маленьких детей, пенсионер, избегающий новых приложений, и сотрудник аэропорта. Они помечены как смоделированные во всех документах, не использовались для персон и не цитируются как доказательства.
| Инсайт | Реальные интервью | Смоделированные | Статус |
|---|---|---|---|
| Фиксированный ранний приезд, независимо от загрузки | 3/4 | 3/4 | Довод |
| Узкое место смещается между досмотром и регистрацией | 3/4 | 2/4 | Довод |
| Идентификация идёт по бумажным документам | 3/4 | 1/4 | Довод |
| Имени и номера рейса может не хватить для идентификации | 0/4 | 1/4 | Гипотеза |
| Менее технологичные пассажиры могут бросить онлайн-регистрацию | 0/4 | 1/4 | Гипотеза |
Поле паспорта появилось из первой гипотезы. Я добавил его всё равно, потому что цена ошибки несимметрична: одно лишнее поле против пассажира, которого не смогут идентифицировать на стойке. Это также согласуется с реальным выводом: паспорт — первый документ, который просят.
Тестирование — неформальное наблюдение не более чем за семью людьми, без записи и без заданий. Аналитика была установлена, но не фиксировала визиты надёжно, поэтому количественных данных нет.
Одна реальная респондентка сказала, что за последний год очередь сама стала быстрее. И всё равно люди приезжают за три часа — значит, проблема в неопределённости, а не в длине очереди.
Я дважды сверил каждый этап карт пути с картой сайта. Экраны без этапа в пути (FAQ, «Связаться с нами», история полётов) ушли, как и окно регистрации при бронировании. В итоговой структуре два состояния с автоматическими переходами между ними. Приёмочный тест основной персоны отмечен на доске как пройденный частично: приложение пока не прогнозирует загрузку регистрации.
Прототип написан на чистых HTML, CSS и JavaScript и размещён на GitHub Pages. Я собрал его с AI-ассистентом для кода по своему файлу Figma и проверял результат экран за экраном. Поиск рейса использует открытые источники без ключей: табло вылетов Управления аэропортов Израиля — для даты, времени и терминала, и базу маршрутов как запасной вариант. Имя и номер паспорта не покидают устройство.
| Поведение | Первая сборка | После доработки |
|---|---|---|
| Окна времени | Примерные значения, скопированные из фрейма Figma | Девять окон по 20 минут, построенных назад от вылета, в одном месте кода |
| Неизвестный рейс | Подставлялся демо-маршрут | Показывает реально введённый номер в нейтральной карточке |
| Доп. пассажиры | Можно было добавить, но не удалить | Удаление с перенумерацией |
Вопрос, который сильнее всего изменил дизайн, возник во время сборки: если окно регистрации целиком зависит от непредсказуемого досмотра, зачем вообще предлагать его как выбор? Он убрал целый селектор с экрана регистрации.
