Редизайн процесса Регистрации и Выписки в отельном сервисе
UX&UI Design Case Study / Booking Service
Экспозиция
Клиент нашел меня на Upwork. Дэйв — типичный продакт из Нью-Йорка, мечтающий заработать денег на своем продукте, сделав пользователей своего сервиса счастливыми.
Пару лет назад он создал Booking Ninja — сервис, который помогает владельцам и администраторам отелей в работе с клиентами. В общем, это обычная CRM-система построенная внутри Force Sales, с очень запутанными внутренними процессами и просто взрывающими мозг интерфейсными решениям.
Создавалась она программистами, а это значит, что она работает понятным образом только для них самих.
Определение проблемы
Дэйву круглосуточно сыпятся жалобы на почту. Из тех, которые оказались наиболее важными и актуальными для бизнеса, он делает задачи и ставит их своей маленькой команде. За пару лет накопилось тысячи слипшихся друг с другом жалоб на интерфейс.
Мы сели в zoom и перебрали все жалобы и отсортировали их используя два критерия — популярность упоминания и влияние на доход.
Оказалось, что чаще всего клиенты жалуются на процесс Регистрации и Выписки. Эти воронки больше всего влияют на доход отелей, поэтому редизайнить решили именно их.
Разбор процесса
Процесс Регистрации гостя начинается с того, что администратор должен внести его в базу данных, и только после этого он имеет возможность забронировать ему номер для проживания. Происходит это в телефонном режиме, в котором администратор устно расспрашивает у гостя его данные. Из-за этого часто возникают ошибки в заполнении любых форм, где нужны буквы.
В момент заселения, когда клиент появляется на пороге отеля с уставшим видом и паспортом в руках, администратор, если есть какие-то ошибки, вынужден редактировать информацию сначала в базе данных, а затем регистрировать гостя через модальное окно. Пользователь не просто делает много лишних действий, он задерживает уставшего гостя на пороге отеля.
Перед тем, как вмешаться, нужно знать какую конкретно проблему необходимо устранить. Если ее сформулировать, то она звучит примерно так:
Пользователь тратит много времени на заполнение форм, находящихся в разных частях сервиса.
Метрикой, которая четко ответила бы что проблема решена, я выбрал увеличения конверсии и сокращение количества жалоб.
Исследования популярных практик
К сожалению, к конкурентным продуктам мне доступ был закрыт. Я начал искать схожее решение по Регистрации на альтернативных сервисах. Взял ключевые сервисы по бронированию жилья и сделал скриншоты интерфейсов.
Кроме некоторых мелочей, из хороших практик я выделил:
– Объединение элементов интерфейса по категориям;
– Пользователю хорошо видно состояние процесса в общем;
– Процесс разделен по шагам;
– Пользователь имеет возможность исправлять информацию на предыдущих шагах.
Идеи:
Во-первых, давайте сначала наведем порядок, рассортировав всю информацию по категориям;
Во-вторых, избавимся от лишних форм, которые черт знает кому нужны;
В-третьих, из категорий сделаем шаги, по которым должен пройти пользователь;
Ну и четвертое, уведомим пользователя, что он завершил процесс успешно и дадим возможность зарегистрировать нового гостя.
Процесс
- Сортируем
Здесь просто, так как отсутствуют конфликтующие между собой сущности, в процессе Регистрации и Выписки логичным есть задать три вопроса: Куда? Кто? Как? Первое “куда” мы ставим перед “кто”, так как сначала имеет смысл проверить доступны ли желаемые гостю номера.
2. Убираем лишнее
Большинство пунктов оказались нужны. Что-то нужно было для налоговой, а что-то сервису. По итогу:
– Соединил пункты Country и City/Province, так как зачем пользователю делать то, что возможно сделать кодом;
– Тоже самое и с пунктом Age и Postal Code;
3. Соединяй и ускоряй
Из вопросов вытекают категории Reservation Details (Куда?), Guest Personal Information (Кто?), Payment (Как?), Additional Services (Второе Как?), ну и третье Check Out (Как?).
Второе “Как?” появилось в последний момент и пришлось поместить его в отдельный аккордеон, так как клиент настоял, что это нужно как-то показать. Для отельного бизнеса крупную долю дохода приносят именно дополнительные услуги.
Имея четкие категории, я сделал из них шаги.
Сборка компонентов
Здесь мне осталось лишь отрисовать GUI. Но здесь я наткнулся на типичную трудность — предыдущий дизайнер оставил UI Kit в виде нескольких *psd макетов Панели управления, и конечно, оказалось что этого мало. Пришлось перерисовать многие элементы в Figma, так чтобы с ними возможно было работать в будущем.
Получилось пять групп элементов:
4. Съедаем большую рыбу кусками
Пользователю необходимо понимание того, когда процесс начат и когда закончен. После завершения, ему стоит предложить создать новый процесс. Это я поместил на отдельное модальное окно в конце каждого процесса.
Передача решения в разработку
После согласования решения с клиентом, я собрал все необходимые материалы и предоставил их разработчикам. Обычно, я стараюсь сделать все в таком виде, чтобы возникающие вопросы исчерпывались на экране Figma и не переходили в месседжер ко мне или к клиенту.
При подготовке я всегда использую эту схемку и задаю много глупых вопросов разработчикам. Это значительно сокращает время на передачу материалов в разработку.
Ответственность
Она не заканчивается после сдачи проекта в разработку. Дизайнер продукта — это ответственность не за ответ в Slack в пределах часа, а ответственность за свое положительное влияние на продукт, его команду и всех, кто этим продуктом пользуется.
Результат
Пользователь знает где он находится, он понимает, что ему нужно делать. Мы не заваливаем пользователя информацией и не пытаемся вызвать когнитивный коллапс в его голове, а просто берем его за руку и ведем к его цели, шаг за шагом.
После имплементации решения конверсия Регистрации увеличилась на +19,4%, Выписки на +15%, а популярность упоминания в жалобах вовсе исчезла. Вместо этого появилось два положительных отзыва. Это очень хороший результат.
Среднее время прохождения воронки Регистрации занимает 1:50 сек, Выписки — 0:16 сек. Думаю, что время может стать хорошей дополнительной метрикой в следующей дизайн-итерации.
