Кроме некоторых мелочей, из хороших практик я выделил:
– Объединение элементов интерфейса по категориям;
– Пользователю хорошо видно состояние процесса в общем;
– Процесс разделен по шагам;
– Пользователь имеет возможность исправлять информацию на предыдущих шагах.
Содержание статьи
Идеи:
Во-первых, давайте сначала наведем порядок, рассортировав всю информацию по категориям;
Во-вторых, избавимся от лишних форм, которые черт знает кому нужны;
В-третьих, из категорий сделаем шаги, по которым должен пройти пользователь;
Ну и четвертое, уведомим пользователя, что он завершил процесс успешно и дадим возможность зарегистрировать нового гостя.
Процесс
- Сортируем
Здесь просто, так как отсутствуют конфликтующие между собой сущности, в процессе Регистрации и Выписки логичным есть задать три вопроса: Куда? Кто? Как? Первое “куда” мы ставим перед “кто”, так как сначала имеет смысл проверить доступны ли желаемые гостю номера.
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 в пределах часа, а ответственность за свое положительное влияние на продукт, его команду и всех, кто этим продуктом пользуется.
Результат
Пользователь знает где он находится, он понимает, что ему нужно делать. Мы не заваливаем пользователя информацией и не пытаемся вызвать когнитивный коллапс в его голове, а просто берем его за руку и ведем к его цели, шаг за шагом.
Загрузка...
