Разработка конструктора путешествий: процесс глазами арт-директора. Часть 3

Как мы придумали новый, немного революционный, вид запроса на путешествие и что из этого получилось. Это продолжение дневника, предыдущие части читайте здесь.

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

Самая первая версия заполненного запроса, с которой я презентовал идею команде.

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

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

На каждом шаге заполнения запроса пользователю предлагаются простые и понятные действия. В итоге получается словесное описание его будущего путешествия.

Для того, чтобы более адекватно проверить поведение такого запроса на большем количестве случаев и комбинаций мы распечатали все «кванты», из которых может состоять запрос, и складывали из них «молекулы» — предложения:

Несколько типов «квантов» в будущих «молекулах» запроса.

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

Целый день вчера мы провели в попытках «разломать» принятую ранее как перспективную «половинчатую» схему верстки экранов сервиса. Смысл схемы был в том, что большинство экранов будет представлять собой две большие половины, например, слева мы будем видеть и править запрос, а справа сразу будем видеть рассчитанный маршрут.

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

Если вспомнить нашу главную установку — предлагать пользователю простые шаги и показывать только самую необходимую информацию, то половинчатая схема часто будет идти с ней врозь —мы всегда показываем пользователю две сущности, например, список отелей и детальное описание одного из них. Получается достаточно плотный и нагруженный интерфейс. И чем дальше в правки и настройки — тем плотнее и дальше от простоты и лаконичности. Так что схему мы, похоже, поломали, и сейчас моя задача — придумать новую, упрощённую и интуитивную. И конечно, я доволен, что к такому решению мы пришли не на этапе дизайна. Как же полезны ранние «пристрельные» прототипы!

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

Пункты меню:
• профиль пользователя,
• сохранённые маршруты,
• контакты пользователя,
• валюта,
• язык,
• забронированное,
• покупки,
• вход / регистрация / восстановление пароля,
• подписка на новости,
• помощь,
• блог сервиса.

Модули:
• запрос,
• рассчитанный маршрут,
• карта,
• календарь,

Списки и подробные описания:
• перелёт,
• переезд,
• отель,
• пользователь,
• группа,
• контролы для списков (табы, пагинация, сортировка, поиск, фильтрация).

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

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

Andrey Belikov, арт-директор IQPlanner.com