{"id":2175,"url":"\/distributions\/2175\/click?bit=1&hash=803b6e1bcbd9dfc4ba9456fda887a878c80d24df8d3a575913b14876e18923a5","title":"TJ \u0437\u0430\u043a\u0440\u043e\u0435\u0442\u0441\u044f 10 \u0441\u0435\u043d\u0442\u044f\u0431\u0440\u044f \u2014\u00a0\u043f\u0440\u043e\u0447\u0438\u0442\u0430\u0439\u0442\u0435 \u0430\u043d\u043e\u043d\u0441 \u0441 \u0434\u0435\u0442\u0430\u043b\u044f\u043c\u0438","buttonText":"\u0427\u0438\u0442\u0430\u0442\u044c","imageUuid":"d1d355d8-93a3-5140-aeae-14b03046b760","isPaidAndBannersEnabled":false}
Рустам Байбулатов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инсайт:

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

Рассказать про детали реализации всего проекта?
Да
Нет​
🤷‍♀️
Показать результаты
Переголосовать
Проголосовать
0
Комментарии
Читать все 0 комментариев
null