Почему User-Flow так важен в UI/UX-проектах?

Недавно работал над проектом, в котором надо было спроектировать интерфейс окна очереди в больнице.

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

Макет интерфейса, предлагаемый заказчику

Хорошая идея? Да, к тому же удобно: ведь не всегда понятно, к какому именно врачу в кабинете нужно подходить, если в кабинетах по несколько специалистов, что и было в нашем случае.

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

И тут вскрылась проблема – оказывается, в очередь запись может идти не к конкретному врачу, а в кабинет, где врачи уже сами могут распределить между собой пациентов по мере освобождения. Т.е. на табло не выводится фотография и ФИО врача, что сказывается на дизайне интерфейса – возникает пустота, причем заметная, т.к. на весь экран диагональю 55” приходится всего 4 строки.

Проблемная область

Причем даже сам Заказчик не подумал о таком возможном сценарии на стадии предложения идеи.

Пришлось в последний момент выходить из положения – делать полупрозрачными ФИО и фото одного из врачей, сидящего в кабинете. Это удовлетворило заказчика, но не меня как UI/UX-дизайнера, т.к. такой дизайнерский ход вводил в небольшое заблуждение пациента, сидящего в очереди. Но на тот момент это было единственным подходящим, на мой взгляд, решением.

Финальный вариант с дизайн-решением

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

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

Такого рода ошибка приводит к негативным последствиям – перерисовка / дорисовка макетов интерфейса, что иногда очень трудозатратно, и вдвойне трудозатратнее, если работаете в команде, т.к. дополнительная нагрузка ляжет еще и на разработчиков, которым придется тратить свое время на переработки / доработки. Далее – это скажется на всей команде, т.к. вместо того, чтобы компании взять взять новый проект, придется заниматься еще не сданным проектом.

В конечном счете все это может стоить репутации дизайнеру.

И это, кстати, еще пример того, как дизайнерские “идеальные” макеты сталкиваются с суровой реальностью.

Инсайт:

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

Рассказать про детали реализации всего проекта?
Да
Нет
🤷‍♀️
Показать результаты
Переголосовать
Проголосовать
0
38 комментариев
Написать комментарий...
Туалетный Утёнок

Ребята вы не в ту сторону воюете! Все что мне нужно от этого экрана, сколько мне ждать и куда идти, на кой черт мне фото и имена специалистов если я к ним не записан на прямую!? Все что тут явно напрашивается, это статистика по ожиданию

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Фото и имена были реализованы как дополнение. А вообще – согласен.

Насчет времени ожидания – было бы неплохо.

Ответить
Развернуть ветку
Sergey Vidyakin

если бы еще каждому врачу дать кнопочку в программе, чтоб он сам выставлял примерную оценку времени, а не среднестатистическую или нормативную выводить

Ответить
Развернуть ветку
Maxim Syabro
 вскрылась проблема – оказывается, в очередь запись может идти не к конкретному врачу, а в кабинет, где врачи уже сами могут распределить между собой пациентов по мере освобождения

И да, проблема не "вскрылась", а проблема в том что у вас дизайнеры ножками не ходили по клинике. И бизнес-процессы плохо или вообще не формализованы

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Дизайнеры ходили и не один раз, оказались просто не проникнуты всей схемой работы данного процесса.

Ответить
Развернуть ветку
Maxim Syabro

Почему не поставить нарисованый аватар + написать "Врач будет назначен в кабинете"? Или без аватара вообще. 

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Пробовали ставить нарисованный – выглядит слишком выбивающимся из всего стиля.
А без аватара – слишком "дыряво".

Ответить
Развернуть ветку
Sergey Vidyakin

Знак вопроса рисовать тоже не стильно?

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Не понял мысли)

Ответить
Развернуть ветку
Sergey Vidyakin

ну кружочек и в нем "?"

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Как вариант. 

Ответить
Развернуть ветку
Anton Z.

один светлый фон, одинаковые светлые халаты, практически одна прическа, одна поза. будут ли посетители вообще различать лица - хз. 

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Хороший вопрос 🤔

Ответить
Развернуть ветку
Vl Al

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

Из недавнего посещения поликлиники - время начала приема работает только для первого пациента. Для всех остальных оно может "уехать" на час-другой. Запросто.

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

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

Ответить
Развернуть ветку
Виталий Асташкин

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

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Изначально и лого было по левому краю, но заказчик просил по центру. Не стал настаивать в этом случае на своем.

Насчет прозрачности – думаю, так лучше, чем ставить иллюстрированное изображение. Хотя, возможно, есть и более эстетичное решение. 

Ответить
Развернуть ветку
Виталий Асташкин

Можно попробовать другую группировку элементов. При таком виде "пустота" уже не так страшна

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Тут сомневаюсь. Здесь уже и текст мал, учитывая, что возраст пациента может достигать 70 лет, у которых зрение плохое.

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

Ответить
Развернуть ветку
Sergey Vidyakin

можно в нижней серой части сделать "слайды" с крупной фоткой и ФИО, менять их раз в 3-5 секунд, для каждого пункта списка

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

В этом боксе планируется помещать видео с субтитрами.

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Хотя, сейчас смотрю на свой же макет и вижу, что размер текста почти сравним с вашим. Значит, видимо, не такой уж он и малый, т.к. мы проводили тестирование, выводив макеты на сами экраны в реале.

Ответить
Развернуть ветку
Виталий Асташкин

Будет интересно узнать подробнее о реализации всего проекта, может к моменту новой статьи и этот вопрос решится

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Может быть)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Sergey Vidyakin

То что пользователь смотрит - уже взаимодействие, просто в голове. Траектория движения глаз, понятность, читаемость - тоже создают "пользовательский опыт"

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Sergey Vidyakin

ну строго говоря в UX нет слова "взаимодействие". Пользовательский опыт возможен и без взаимодействия - главный критерий это помогает ли "пользователю больницы" этот монитор или наоборот с ним хуже. Тогда это был бы отрицательный пользовательский опыт

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Соглашусь.

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Если говорить напрямую – взаимодействия с самим таблом нет, но взаимодействие происходит с терминалом, где уже на табло выводится некий результат взаимодействия.

Может, я и ошибаюсь, называя это UX.

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Каким термином, по-вашему, называется такое взаимодействие?
Я, честно говоря, не знаю.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Скворцов

Пользовался однажды приложением - уже не помню, как называется - был прекрасный функционал, у конкурентов подобного не было и в помине, но из-за отвратного флоу и UI я просто не мог пользоваться без мучений. Итог - удалил, иногда приложение было очень нужно, но я предпочитал обходиться без него, ибо остались слишком негативные впечатления. Так что флоу - очень важная штука, ее стоит продумывать максимально детально и не только своими силами, но и силами ЦА, в идеале

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

Тоже удалял такие приложения

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Рустам Байбулатов
Автор

:)

Ответить
Развернуть ветку
Алексей Тараканов

а при чем тут user flow? 

Ответить
Развернуть ветку
35 комментариев
Раскрывать всегда